Conventions Ruby on Rails

Bonjour,

J’aime beaucoup l’idée des conventions à la place de la configuration
de Ruby on Rails. Cependant , je ne sais pas où se trouve “la bible”
de toutes les conventions sur lesquelles s’appuie Rails.

Pour l’instant je les découvre souvent en ayant de suppositions
erronées qui conduisent à du code qui ne marche pas, et en cherchant
ce qui ne fonctionne pas, je trouve, ici un blog, ici un screencast
qui détaille le point précis et explique la convention que j’ignorais.

Exemple:

J’ai l’habitude de mettre un id sur toutes mes tables, même pour les
tables de jointure. On 'a dit a une époque que c’est mieux pour la
base de données, j’ai suivi.

Aujourd’hui un dévelopeur rails me dit, non pas du tout, ça sert a
rien un id sur une table de jointure. il faut pas en mettre.
La je comprends qu’il pense que les algorythmes internes des bases de
données ignorent les ids, alors qu’on m’avait dit le contraire. j’ai
pas les moyens de savoir qui a raison.

En réalité je manipule des volumes suffisemant faible pour que ce soit
indifférent. je m’en fiche un peu.

Mais rails ne s’en fiche pas du tout.
si j’utilise has_many_and_belongs_to_many , Rails a besoin que je ne
mette pas d’id, sur la table de jointure
si j’utilise has_many …:through , Rails a besoin du contraire, je
dois mettre un id sur la table de jointure.

Globalement je trouve la convention de Rails assez sensée et logique,
mais j’ai vraiement besoin de savoir qu’elle existe.

Combien de conventions ignore-je encore ??, je ne sais :slight_smile:

d’ou ma question, existe t il un document qui rescence toutes les
conventions de Rails ?

Merci d’avance pour toute suggestion

Stéphan.

Le choix de mettre un id ou non dans une table de jointure est déterminé
par
la cardinalité. Tu as 2 objets a et b de type A et B.

Si la table de jointure ne contient pas d’id, alors la clef primaire est
le
groupe des deux clefs étrangères. Donc a et b pourront avoir qu’une
seule
association. Et inversement on rajoute un id à cette table pour que a et
b
puisent avoir plusieurs associations. Donc c’est un choix pas annodin du
tout !

À mon avis les algos internes s’en moquent bien du champ id, car le
SGBDR a
ses propres id internes.

Pour répondre à ta question principale à part api.rubyonrails.com je ne
connais rien d’autre.

Alexis.

Le 30 novembre 2008 13:55, [email protected]
[email protected] a
écrit :