0

EDIT: Cela peut aider à obtenir au point de ma question ...ne peut pas accéder emboîtées beaucoup à plusieurs has_many: à travers les associations de l'objet parent

est-il un moyen de faire « en cascade » par: associations? Par exemple, si nous allons avec la chanson des os: "L'os du pied est connecté à l'os de la cheville, l'os de la cheville est connecté à l'os de la jambe, l'os de la jambe est connecté à l'os de la hanche ..." Je ne veux pas dire que le pied a plusieurs hanches, parce que ce n'est pas tout à fait exact. Je ne veux pas non plus dire que le pied a beaucoup de hanches à travers la jambe (car il faut aussi passer à travers la cheville). Non, à la place, le pied a_many hanches à travers la cheville qui est à travers la jambe. Le pied est connecté à une cheville, et cet assemblage foot_ankle est alors connecté à une jambe, puis tout l'ensemble foot_ankle_leg est finalement attaché à une hanche. Ainsi, un pied peut avoir de nombreuses hanches, mais le pied n'appartient pas à une hanche isolée, l'association n'existe que dans le cadre d'une assemblée particulière foot_ankle_leg.

Pour représenter quelque chose comme ceci, ai-je raison de mettre en place ceux qui se trouvent entre les tables pour "porter" les connexions pied/cheville/jambe jusqu'à la hanche? (Ie la table a_b_c_d_e représente quelque chose de semblable à une "finale" ensemble foot_ankle_leg_hip)


QUESTION ORIGINAL: Avoir plusieurs modèles qui se réunissent avec divers intervenants many-to-many: grâce à des tables. HABTM n'est pas utilisé car ces tables traversantes contiennent des attributs supplémentaires.

Voici une image de la façon dont elle s'emboîte, les boîtes vertes sont les tables de jointure plusieurs-à-plusieurs. Par souci de concision, renommé lettres

Database chart

Voici comment la structure est codée

class A < ApplicationRecord 
    has_many :a_bs 
    has_many :bs, through: :a_b 
... 
end 

class B < ApplicationRecord 
    has_many :a_bs, 
    has_many :as, through: :a_b 
... 
end 

class AB < ApplicationRecord 
    belongs_to :a 
    belongs_to :b 
    has_many :a_b_c_ds 
    has_many :c_ds, through: :a_b_c_d 
... 
end 

class C < ApplicationRecord 
    has_many :c_ds 
    has_many :ds, through: :c_d 
... 
end 

class D < ApplicationRecord 
    has_many :c_ds 
    has_many :cs, through: :c_d 
... 
end 

class CD < ApplicationRecord 
    belongs_to :c 
    belongs_to :d 
    has_many :a_b_c_ds 
    has_many :a_bs, through: :a_b_c_d 
... 
end 

class ABCD < ApplicationRecord 
    belongs_to :a_b 
    belongs_to :c_d 
    has_many :a_b_c_d_es 
    has_many :es, through: :a_b_c_d_e 
... 
end 

class E < ApplicationRecord 
    has_many :a_b_c_d_es 
    has_many :a_b_c_ds, through: :a_b_c_d_e 
... 
end 

class ABCDE < ApplicationRecord 
    belongs_to :a_b_c_d 
    belongs_to :e 
... 
end 

Chaque fois que je tente d'accéder à des enfants imbriqués de l'objet parent dans la console, quelque chose comme A.first.a_b_c_ds, il retourne

#<ABCD::ActiveRecord_Associations_CollectionProxy:0x26ca578>.

Est-ce ce que je devrais voir? Ai-je besoin d'interagir directement avec CollectionProxy plutôt que de voir la sortie des enregistrements "habituels"? Si oui, c'est quelque chose de nouveau dont je vais avoir besoin :)

Dans la lecture, je remarque aussi qu'il essaie de trouver l'identifiant du parent dans la table de passage plutôt que l'identifiant "enfant" associé .

ABCD Load (0.3ms) SELECT "a_b_c_ds".* FROM "a_b_c_d" WHERE "a_b_c_d"."a_id" = ? [["a_id", 1]] 

Maintenant, évidemment, la a_id ne sera pas dans le tableau ABCD. Mais ab_id est là, lequel est associé à a_id. Et si je lis correctement le rail-guide, les rails devraient être assez intelligents pour faire cette distinction si je le configure correctement.

Une idée dans laquelle je fais un mauvais virage?

Les noms de classe ne sont pas nécessairement alphabétiques. Par exemple, Wrapping, Package, Object, WrappingPackage, WrappingPacakgeObject. Mais depuis que j'utilise les tables many-to-many, je crois comprendre que les noms des tables ne devraient pas avoir d'importance. Cela ne joue que lorsque vous utilisez has_many_and_belongs_to rejoindre des tables. Mais est-ce là où je m'en vais?

Merci pour votre aide!Faites-moi savoir si vous avez besoin de plus d'extraits!

+1

Votre exemple: 'A.first.a_b_c_ds' semble faux, il n'y a pas d'association' a_b_c_ds' dans A. –

+0

Ahhh, d'accord! Donc, si je vous entends correctement, les associations ne s'empilent pas automatiquement ou en cascade comme l'héritage de classe? Les associations doivent être définies explicitement dans la «chaîne de données» en tant que telle? – Spectator6

Répondre

1

Chaque appel appartenant à ou has_many crée une méthode d'association dans toutes les instances de la classe.

Alors quand vous faites:

class A 
    has_many bs 
end 

class B 
    has_many cs 
end 

vous méthode essentiellement ajouté bs aux instances de tous les A. Il n'y a pas de méthode cs dans A et il n'y a pas d'autre magie impliquée.

+0

Ok, ça a du sens! Alors, y a-t-il un moyen de faire comme un doublé ou un triple à travers? Par exemple, si nous allons avec la chanson des os: "L'os du pied est connecté à l'os de la cheville, l'os de la cheville est connecté à l'os de la jambe, l'os de la jambe est connecté à l'os de la hanche ..." Je ne veux pas dire que le pied a de nombreux hanches. Je ne veux pas non plus dire que le pied a beaucoup de hanches à travers la jambe (car il faut aussi passer à travers la cheville). Pour représenter quelque chose comme ça, ai-je raison de mettre en place ces entrelacs à travers des tables pour "porter" les connexions pied/cheville/jambe jusqu'à la hanche? – Spectator6