Forum: Italian Ruby user group Limiti di Ruby On Rails

Cosa ne pensate?
(articolo disponibile a
http://www.tonymarston.net/php-mysql/radicore-vs-ror.html)

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Deficiencies in Ruby On Rails
Here are some of the deficiencies which I have found (so far):

1. 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.

2. 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.

3. 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.

4. Relationships are inferred from foreign key names
All foreign keys must be named in the format <singular of foreign table
name>_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.

5. 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.

6. 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.

On 11/29/06, Peppino <gicigala@tin.it> wrote:
> Cosa ne pensate?
> (articolo disponibile a
> http://www.tonymarston.net/php-mysql/radicore-vs-ror.html)

...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 <polemica>cosa non si fa per catturare 
audience</polemica>
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.

<IMHO>
e-chi-se-ne-frega ?
;-)
<IMHO>

[1] http://en.wikipedia.org/wiki/Ruby_on_rails#Philosophy

michele

--
Michele Franzin
SeeSaw | Another point of view
http://www.seesaw.it
michele.franzin@seesaw.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.
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:

La mia domanda: meglio "radicore" o "servoy" ?;-)

--
David N. Welton
 - http://www.dedasys.com/davidw/

Linux, Open Source Consulting
 - http://www.dedasys.com/

On 11/29/06, Peppino <gicigala@tin.it> wrote:
>
> 1. Table names must be plural

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.

M

Quoting Giovanni Intini <intinig@pme.it>:

> La 6 in effetti è un problema

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? :-)

Quoting Peppino <gicigala@tin.it>:

> Cosa ne pensate?
> (articolo disponibile a
> http://www.tonymarston.net/php-mysql/radicore-vs-ror.html)

Non ho resistito, ho dovuto dirgliene 4 :-)
Il topic e' qui:

http://www.radicore.org/forum/index.php?t=msg&goto=431

ditemi pure se ho scritto qualche strafalcione...

On 11/30/06, stefano@tomato.it <stefano@tomato.it> wrote:
> Non ho resistito, ho dovuto dirgliene 4 :-)
> Il topic e' qui:
>
> http://www.radicore.org/forum/index.php?t=msg&goto=431
>
> ditemi pure se ho scritto qualche strafalcione...

mitico!

--
Michele Franzin
SeeSaw | Another point of view
http://www.seesaw.it
michele.franzin@seesaw.it

On Nov 29, 2006, at 9:31 PM, David Welton 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 :-)

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 Cobianchi <stefano@tomato.it> ha scritto:
On Nov 29, 2006, at 9:31 PM, David Welton 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 :-)

--
Stefano Cobianchi
stefano@tomato.it



_______________________________________________
Ml mailing list
Ml@lists.ruby-it.org
http://lists.ruby-it.org/mailman/listinfo/ml


 __________________________________________________
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

On Nov 29, 2006, at 7:20 PM, Giovanni Intini wrote:

> 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).

--
Stefano Cobianchi
stefano@tomato.it

Il giorno 30/nov/06, alle ore 10:06, Stefano Cobianchi ha scritto:

Scusa probabilmente ho letto male io, ma puoi avere una primary_key
string?

On Nov 30, 2006, at 10:10 AM, Giovanni Intini wrote:

>
> Il giorno 30/nov/06, alle ore 10:06, Stefano Cobianchi 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 Cobianchi 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).

On Nov 30, 2006, at 11:11 AM, Giovanni Intini wrote:

>
> Il giorno 30/nov/06, alle ore 11:09, Stefano Cobianchi 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).

Quindi rettifico: direi di si' :-)

--
Stefano Cobianchi
stefano@tomato.it

> 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...

--
David N. Welton
 - http://www.dedasys.com/davidw/

Linux, Open Source Consulting
 - http://www.dedasys.com/

Ok, stavo cercando fra la documentazione se fosse possibile, grazie :)

Il giorno 30/nov/06, alle ore 12:51, David Welton ha scritto:

Giovanni Intini wrote:
> Ok, stavo cercando fra la documentazione se fosse possibile, grazie :)
> 
Certo! un esempio da spulciare e' questo plugin:

http://wiki.rubyonrails.org/rails/pages/Uses+Guid+Plugin

che "makes the “ID” field into a 22 character URL-safe GUID."

ciao,
Luca
>>
> 
> 
> _______________________________________________
> Ml mailing list
> Ml@lists.ruby-it.org
> http://lists.ruby-it.org/mailman/listinfo/ml
> 


--

Email mailto://luca.mearelli@gmail.com
Skype callto://l.mearelli

Ho scoperto che adesso puoi anche scrivere sui record con id non
numerici :)

Il giorno 30/nov/06, alle ore 19:08, Luca Mearelli ha scritto:

On 11/30/06, Stefano Cobianchi <stefano@tomato.it> wrote:
> 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,...).

Matteo