C'est équivalent dans les effets, c'est juste plus lisible, plus facile à retoucher, plus propre, et plus facile à faire évoluer à terme.
De toute façon, find avec include ne fait pas forcément ça. Il fait peut-être : SELECT * FROM users LEFT JOIN logs ON users.id = logs.user_id Du coup, quand tu rajoute une condition, ça risque de faire SELECT * FROM users LEFT JOIN logs ON users.id = logs.user_id WHERE users.id = logs.user_id Hop, ce qui commence comme une left join devient tout d'un coup dans les effets une inner join, et exclue donc les users qui n'ont pas de logs à ton insu. ActiveRecord fait porter la "responsabilité" complète de la jointure aux méthodes belong_to, has_one, has_many et has_and_belong_to_many. C'est là que tu met le champs de jointure, et c'est ce sur quoi repose le "include" de find. Si tu ne fais pas comme ça dans un cas trivial comme celui-ci, tu te prive inutilement d'un des intérêts fondamentaux d'ActiveRecord. Et dans le cas que tu as présenté, je ne vois pas de bonne raison pour faire ça. Ensuite, appeller un champs id quand ce n'est pas la clef primaire de la table, là c'est vraiment pas propre, et c'est très probablement ça qui causait ton bug. Ca ne te coûte rien de l'appeller user_id, au contraire ça te permet de faire des clauses rails de jointure sans paramètre supplémentaire pour préciser quelle est la clef étrangère, et ça t'évite aussi d'indiquer à la table logs que le champs "id" n'est pas en réalité la clef primaire. Enfin, c'est une question de paradigme. Un langage de programmation de haut niveau comme Ruby et Rails sert à exprimer dans le code d'une façon simple, lisible, réutilisable. Rien ne t'empêche de faire des choses illisibles, compliquées inutilement et de réinventer la roue si ça te chante. Mon conseil, c'est de faire simple, lisible et réutilisable, même quand tu écris du SQL à la mano, même si tu es un super cador du SQL. De même je n'ai pas tellement envie de repasser derrière un super-crack du code qui appellerait toutes ces variables a, b, c, d, e, f, ... et qui ne commenterais rien. L'idée, c'est de communiquer l'idée, pas seulement à la machine, mais aussi aux autres humains (et à toi-même 3 mois, 6 moins, 5 ans plus tard quand tu rouvre le capot pour voir ce qu'il y avait dedans). Ruby est inventé sur ce concept, les sucres syntaxiques servent à rendre les choses plus claires et plus lisibles, les conventions de Rails aussi. Tu peux les ignorer pour répondre à un besoin particulier, mais les respecter te feras aller plus vite dans les cas triviaux. Michel Belleville --~--~---------~--~----~------------~-------~--~----~ Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de Google Groups. Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse [email protected] Pour résilier votre abonnement envoyez un e-mail à l'adresse [email protected] -~----------~----~----~----~------~----~------~--~---
