^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Deficiencies in Ruby On Rails
Here are some of the deficiencies which I have found (so far):
Table names must be plural
This means that you must use “stories” instead of “story”, “products”
instead of “product”, et cetera. By default the table name is inferred
from the class name, but this can be overridden in the class definition.
Primary keys must be auto_increment and named ‘id’
This for me is an instant turn-off. There is no such rule in any DBMS,
so for a piece of software to insist on such rules simply proves to me
that the author of that software still has a lot to learn:
A primary key does NOT have to be called ‘id’.
A primary key does NOT have to be auto_increment.
A primary key is NOT restricted to a single field.
More of my thoughts on this very subject can be found in Technical Keys
Their Uses and Abuses.
Candidate keys must be … ?
I could not find any description on how the Rails framework deals with
candidate keys, so perhaps this has to be hard-coded by the developer.
Relationships are inferred from foreign key names
All foreign keys must be named in the format _id, so if you want a one-to-many relationship between authors
(note the plural) and stories, you have to use a column called author_id
in stories.
This again is an entirely artificial restriction which does not exist in
any DBMS that I know of, therefore I find it to be entirely
unacceptable.
Intersection tables in Many-to-Many relationships
As everyone knows, Many-to-Many relationships between two tables cannot
be supported in any DBMS without the use of what is known as an
intersection table (also known as a ‘link’ or ‘cross-reference’ or
‘xref’ table). This can then be the object of two One-to-Many
relationships between the original pair of tables. RoR cannot recognise
intersection tables unless they are named according to the rule
alphabeticallyFirstTablePlural_alphabeticallySecondTablePlural.
Primary data validation
RoR does not automatically perform any basic validation on user input
before it is sent to the database, even though such information is
provided in the database schema (this is a string, this is a number,
this is a date, etc). Methods are provided, but you have to insert the
code to activate them.
…che in gran parte non siano limiti di RoR ma del fatto che adotti il
‘Convention Over Configuration Principle’ [1] e al quale semmai
andrebbero
rivolte le critiche cosa non si fa per catturare
audience
Detto questo non credo che siano limiti ma caratteristiche che rendono
il framework ‘opinionated software’ ed estremamente adatto a velocizzare alcune attività, ma non per tutte… lo strumento universale, il
framework
definitivo, il linguaggio totale no saranno nè ruby né rails.
Secondo me la maggior parte di queste obiezioni non sono fondate. La
1, la 4 e la 5 sono false perché tutti questi default possono essere
modificati nel modello, la 2 è vera, ma qui si tratta di convenzioni.
Nel corso di Ing. del Software all’università consigliano di usare
sempre la chiave ID
La 3 non l’ho capita sinceramente. Nel senso che non me ne frega di
sapere quali sono le chiavi candidate dei miei modelli finché ho la
chiave primaria.
La 6 in effetti è un problema, ma anche qui rails adotta la
convenzione di spostare tutta la logica di applicazione nel modello.
Il giorno 29/nov/06, alle ore 17:20, Peppino ha scritto:
Ma dàààài! Cinque minuti spesi a consultare la documentazione e
scopri che non è vero che debbano per forza essere plurali. Se posso
basare i miei argomenti su affermazioni false allora posso criticare
qualsiasi cosa. Nella fattispecie, i punti di questo tizio sono tutti
falsi, tranne il terzo che non significa nulla.
Ha proprio ragione Michele, cosa non si fa per catturare audience.
Ma anche no: se a qualcuno premesse veramente, non ci vorrebbe molto
a scrivere un plugin che aggiunge automaticamente le regole di
validazione
inferendole dallo schema del database.
Che voi sappiate esiste un plugin simile? E se non esiste, sara’ mica
la prova del fatto che NON e’ poi un vero problema?
Se posso dire la mia:
Esistono diversi framework in PHP basati sull’arci-consolidato pattern
MVC.
Il problema di ognuno di questi framework non è tanto nella loro
bontà, quanto
nelle relative community: numericamente minori e meno attive rispetto
a quelle
dietro a Rails. Inoltre Rails ha anche un buon supporto commerciale
(workshop,
libri, eventi, formazione, etc.), seppur solo all’estero.
Stefano C. [email protected] ha scritto:
On Nov 29, 2006, at 9:31 PM, David W. wrote:
La mia domanda: meglio “radicore” o “servoy” ?
Dovendo giudicare dal nome in effetti e’ difficile decidere quale sia
il migliore:
fanno abbastanza schifo entrambi
Do You Yahoo!?
Poco spazio e tanto spam? Yahoo! Mail ti protegge dallo spam e ti da
tanto spazio gratuito per i tuoi file e i messaggi http://mail.yahoo.it
Secondo me la maggior parte di queste obiezioni non sono fondate.
La 1, la 4 e la 5 sono false perché tutti questi default possono
essere modificati nel modello, la 2 è vera, ma qui si tratta di
convenzioni.
La 2 non e’ vera, perche’ a parte il fatto ovvio che la primary key
la puoi chiamare come ti pare, non ci vuole
molto a gestirla senza un auto_increment o equivalenti, per esempio
implementando il metodo #next_sequence_value e facendo
tornare true al metodo #prefetch_primary_key? (l’esempio piu’ stupido
che mi viene in mente: usare una sola sequenza
per generare tutte le chiavi primarie, per avere un keyspace globale).
Il giorno 30/nov/06, alle ore 10:06, Stefano C. ha scritto:
Scusa probabilmente ho letto male io, ma puoi avere una primary_key
string?
Bisognerebbe spulciare il codice (o meglio, chiedere a qualche
sviluppatore del core team) per vedere
se da qualche parte si fa affidamento sul fatto che l’id sia un
intero, ma a naso (= avendo controllato
velocemente l’implementazione di #find_from_ids e #find_one), direi
di no.
Il giorno 30/nov/06, alle ore 11:09, Stefano C. ha scritto:
Allora l’obiezione due è giusta
Il problema non è tanto l’auto_increment quanto l’impossibilità di
usare chiavi primarie non integer (che poi sono alla base della
teoria delle basi di dati).
Aspetta, il mio “direi di no” era riferito al mio quesito (se
ActiveRcord faccia affidamento sul tipo integer),
non alla tua domanda (se si possono avere chiavi di tipo stringa).
Allora l’obiezione due è giusta
Il problema non è tanto l’auto_increment quanto l’impossibilità di
usare chiavi primarie non integer (che poi sono alla base della
teoria delle basi di dati).
Io sono riuscito ad usare una chiave primaria stringa, ma solo in
lettura, che comunque mi bastava…
Il giorno 30/nov/06, alle ore 11:09, Stefano C. ha scritto:
Allora l’obiezione due è giusta
Il problema non è tanto l’auto_increment quanto l’impossibilità di
usare chiavi primarie non integer (che poi sono alla base della
teoria delle basi di dati).
sviluppatore del core team) per vedere
se da qualche parte si fa affidamento sul fatto che l’id sia un
intero, ma a naso (= avendo controllato
velocemente l’implementazione di #find_from_ids e #find_one), direi
di no.
Ho usato chiavi primarie di tipo stringa in Rails. Nessun problema.
Funzionano molto bene per quelle tabelle di supporto tipo le province:
chiave primaria, il codice provincia (MI, RM,…).
