Nous prévoyons de mettre à niveau notre application sur Rails3. Un plugin que nous avons utilisé assez mal est niéd_has_many_through. Ce plugin semble obsolète et n'est plus maintenu et ne semble tout simplement pas fonctionner dans une nouvelle application Rails3.
Un exemple simple: P>
Author.rb has_many :posts has_many :categories, :through => :posts, :uniq => true has_many :related_posts, :through => :categories Post.rb belongs_to :author belongs_to :category Category.rb has_many :posts
3 Réponses :
Je suis plus confus par le has_many: élément associé_posts. Essayez-vous de rejoindre essentiellement des postes classés ensemble? Comme, tous les messages de la catégorie «X» sont considérés comme «liés»? Si tel est le cas, cela ne fonctionnera pas basé sur il n'y a pas d'une classe de comptoir, afin de résoudre ce problème à un minimum nu, vous devez spécifier: class_name sur l'association: mais Deuxièmement, ce n'est probablement pas la bonne approche pour commencer. Depuis tout auteur déjà des publications de HAS_MANY via la clé étrangère de l'auteur_id, il n'a aucun sens pour essayer de revenir à la table des catégories, utilisez plutôt la logique de regroupement. P> Alternativement approches qui nettoient cela: p> Auteur.rb P> has_many :posts do
def related
all.group_by(&:category_id)
end
end
author.posts.related
=> OrderedHash
Je suis enclin à penser que son exemple est injecté (d'où facilement déforme). Sa question est toujours fondamentalement importante. Et au meilleur de ma connaissance, il n'y a pas de solution de travail pour imbriquée avec beaucoup de traverse dans Rails 3 (A la vieille nichée_has_many_through pour rails <2.3)
La dernière partie de sa question mentionnée "recommander la meilleure pratique". Mon point était, si votre application l'exige, il y a probablement un meilleur mécanisme pour la réaliser. ;) Si son exemple est vraiment réussi, il serait incroyablement utile de voir son code actuel.
Assez juste. Il existe définitivement des cas où une personne imbriquée a de nombreuses associations (c'est-à-dire à l'aide de plusieurs jointures intérieures, pour les non-rails folk) est une solution valide et souvent la meilleure. Compte tenu "Auteur - Author.Subscriber_InsTests Serait tous les deux candidats à l'utilisation de l'utilisation de personnes imbriquées , À mon avis. L'autre option consiste à cacher ces associations à tout moment les associations de 1er niveau changent, ce qui est inférieur à l'idéal.
rails 3 (non testés, commandes par des messages avec la plupart des catégories connexes en premier):
catégorie.rb: utilisation:
Ceci est intégré avec des rails 3.1: http://asciicasts.com/ Épisodes / 265-Rails-3-1-Aperçu
Rails giveth and rails prend tout
Haha je viens de trouver votre fourchette GITUB.COM/RELEOD/NEST_HAS_MANY_THROUGH et rappelé cette question et venait ici à vous dire tout sur la fourchette. Et puis j'ai vu votre nom d'utilisateur. Bon travail, je viens de tester cela sur mes rails 3 app et c'est (principalement) travailler. Je passe toute la nuit à essayer de corriger des rails directement conformément à rails.lighthouseApp.com/projects/8994/tickets/... Mais se coincer. Je vais commencer par votre fourchette comme un modèle et je pourrais aller plus loin maintenant!
+1 GITUB.COM/RELEOD/NEST_HAS_MANY_THROUGH Votre fourchette 3 Fork travaille pour moi aussi, l'utilisera jusqu'à ce que des rails 3.1