Relacja wielu do wielu z tym samym modelem w rails?

Istnieje kilka rodzajów relacji wielu do wielu; musisz zadać sobie następujące pytania:]}

• czy chcę przechowywać dodatkowe informacje w Stowarzyszeniu? (Dodatkowe pola w tabeli łączenia.)
• czy skojarzenia muszą być w domyśle dwukierunkowe? (Jeśli post A jest połączony z postem B, to post B jest również połączony z postem A.)

To pozostawia cztery różne możliwości. Przejdę się po nich.

Dla odniesienie: dokumentacja Rails na ten temat . Jest sekcja o nazwie "wiele do wielu" i oczywiście dokumentacja samych metod klasowych.

Najprostszy scenariusz, jednokierunkowy, bez dodatkowych pól

To jest najbardziej zwarty w kodzie.

Zacznę od tego podstawowego schematu dla Twoich postów:

create_table "posts", :force => true do |t|
  t.string  "name", :null => false
end

Dla każdej relacji wielu do wielu, potrzebujesz tabeli join. Oto schemat tego:

create_table "post_connections", :force => true, :id => false do |t|
  t.integer "post_a_id", :null => false
  t.integer "post_b_id", :null => false
end

Domyślnie, Rails będzie nazywać tę tabelę kombinacją nazw dwóch tabel, do których dołączamy. Ale okazało się, że w tej sytuacji, więc postanowiłem wziąć post_connections.

Bardzo ważne jest :id => false, aby pominąć domyślną kolumnę id. Rails chce tę kolumnę wszędzie z wyjątkiem na tablicach join dla has_and_belongs_to_many. Będzie głośno narzekać.

Na koniec zauważ, że nazwy kolumn również są niestandardowe (Nie post_id), aby zapobiec konfliktowi.

Teraz w twoim modelu, po prostu musisz powiedzieć Rails o tych kilku niestandardowych rzeczach. Będzie wyglądał następująco:

class Post < ActiveRecord::Base
  has_and_belongs_to_many(:posts,
    :join_table => "post_connections",
    :foreign_key => "post_a_id",
    :association_foreign_key => "post_b_id")
end

I to powinno po prostu zadziałać! Oto przykładowa sesja irb przebiegająca przez script/console:

>> a = Post.create :name => 'First post!'
=> #<Post id: 1, name: "First post!">
>> b = Post.create :name => 'Second post?'
=> #<Post id: 2, name: "Second post?">
>> c = Post.create :name => 'Definitely the third post.'
=> #<Post id: 3, name: "Definitely the third post.">
>> a.posts = [b, c]
=> [#<Post id: 2, name: "Second post?">, #<Post id: 3, name: "Definitely the third post.">]
>> b.posts
=> []
>> b.posts = [a]
=> [#<Post id: 1, name: "First post!">]

Przekonasz się, że przypisanie do asocjacji posts spowoduje utworzenie rekordów w tabeli post_connections odpowiednio.

Kilka rzeczy do zapamiętania:

• widać na powyższej sesji irb, że Asocjacja jest jednokierunkowa, ponieważ po a.posts = [b, c], Wyjście b.posts nie zawiera pierwszego posta.
• inną rzeczą, którą mogłeś zauważyć, jest to, że nie ma modelu PostConnection. Zwykle nie używa się modeli do asocjacji has_and_belongs_to_many. Z tego powodu nie będzie można uzyskać dostępu do żadnych dodatkowych pól.

Jednokierunkowe, z dodatkowymi polami

Chcesz więc jasno zaznaczyć w swojej bazie, że post B jest skarceniem na post A. Aby to zrobić, chcesz dodać pole category do asocjacji.

Potrzebujemy już nie has_and_belongs_to_many, ale kombinacji has_many, belongs_to, has_many ..., :through => ... i dodatkowy model dla stołu join. Ten dodatkowy model daje nam moc dodawania dodatkowych informacji do Stowarzyszenia siebie.

Oto kolejny schemat, bardzo podobny do powyższego:

create_table "posts", :force => true do |t|
  t.string  "name", :null => false
end

create_table "post_connections", :force => true do |t|
  t.integer "post_a_id", :null => false
  t.integer "post_b_id", :null => false
  t.string  "category"
end

Zauważ jak w tej sytuacji, post_connections czy mA id kolumnę. (There ' s no :id => false parametr.) Jest to wymagane, ponieważ do dostępu do tabeli będzie dostępny zwykły model ActiveRecord.

Zacznę od modeluPostConnection, bo to jest ŚMIERTELNIE PROSTE:

class PostConnection < ActiveRecord::Base
  belongs_to :post_a, :class_name => :Post
  belongs_to :post_b, :class_name => :Post
end

Dzieje się tu tylko :class_name, co jest konieczne, ponieważ Rails nie może wywnioskować z post_a lub post_b że mamy tu do czynienia z postem. Musimy powiedzieć to wprost.

Teraz Post model:

class Post < ActiveRecord::Base
  has_many :post_connections, :foreign_key => :post_a_id
  has_many :posts, :through => :post_connections, :source => :post_b
end

Z pierwszym has_many Stowarzyszeniem, mówimy modelowi, aby dołączył post_connections na posts.id = post_connections.post_a_id.

Z drugim asocjacją, mówimy Rails ' owi, że możemy dotrzeć do innych stanowisk, tych połączonych z tym, poprzez nasze pierwsze Asocjacje post_connections, a następnie post_b asocjację PostConnection.

Brakuje tylkojeszcze jednej rzeczy i to jest że musimy powiedzieć Rails ' owi, że a PostConnection jest zależne od postów, do których należy. Gdyby jedno lub oba z post_a_id i post_b_id były NULL, to to połączenie niewiele by nam powiedziało, prawda? Oto jak to robimy w naszym modelu Post:

class Post < ActiveRecord::Base
  has_many(:post_connections, :foreign_key => :post_a_id, :dependent => :destroy)
  has_many(:reverse_post_connections, :class_name => :PostConnection,
      :foreign_key => :post_b_id, :dependent => :destroy)

  has_many :posts, :through => :post_connections, :source => :post_b
end

Poza drobną zmianą składni, dwie prawdziwe rzeczy są tutaj różne:

• has_many :post_connections ma dodatkowy parametr :dependent. Z wartością :destroy, mówimy Rails ' owi, że gdy ten post zniknie, może dalej niszczyć te obiekty. Na alternatywną wartością, którą możesz tu użyć, jest :delete_all, która jest szybsza, ale nie wywoła żadnych destroy hooków, jeśli ich używasz.
• dodaliśmy has_many asocjację dla odwrotnych połączeń, również tych, które połączyły nas poprzez post_b_id. W ten sposób Rails może je równie dobrze zniszczyć. Zauważ, że musimy tutaj podać :class_name, ponieważ nazwa klasy modelu nie może być już wnioskowana z :reverse_post_connections.

Z tym na miejscu, przynoszę ci kolejną sesję irb przez script/console:

>> a = Post.create :name => 'Eels are delicious!'
=> #<Post id: 16, name: "Eels are delicious!">
>> b = Post.create :name => 'You insensitive cloth!'
=> #<Post id: 17, name: "You insensitive cloth!">
>> b.posts = [a]
=> [#<Post id: 16, name: "Eels are delicious!">]
>> b.post_connections
=> [#<PostConnection id: 3, post_a_id: 17, post_b_id: 16, category: nil>]
>> connection = b.post_connections[0]
=> #<PostConnection id: 3, post_a_id: 17, post_b_id: 16, category: nil>
>> connection.category = "scolding"
=> "scolding"
>> connection.save!
=> true

Zamiast tworzyć asocjację, a następnie osobno ustawiać kategorię, Możesz również utworzyć PostConnection i zrobić to:

>> b.posts = []
=> []
>> PostConnection.create(
?>   :post_a => b, :post_b => a,
?>   :category => "scolding"
>> )
=> #<PostConnection id: 5, post_a_id: 17, post_b_id: 16, category: "scolding">
>> b.posts(true)  # 'true' means force a reload
=> [#<Post id: 16, name: "Eels are delicious!">]

>> a.reverse_post_connections
=> #<PostConnection id: 5, post_a_id: 17, post_b_id: 16, category: "scolding">
>> a.reverse_post_connections = []
=> []
>> b.posts(true)  # 'true' means force a reload
=> []

Dwukierunkowe zapętlone skojarzenia

W normalnych has_and_belongs_to_many asocjacjach, Asocjacja jest zdefiniowana w obu modelach . A stowarzyszenie jest dwukierunkowa.

Ale jest tylko jeden model Post w tym przypadku. A stowarzyszenie jest określone tylko raz. Właśnie dlatego w tym konkretnym przypadku skojarzenia są jednokierunkowe.

To samo dotyczy alternatywnej metody z has_many i modelu dla tabeli join.

Jest to najlepiej widoczne, gdy po prostu uzyskasz dostęp do skojarzeń z irb i spojrzysz na SQL, który rails generuje w pliku dziennika. Znajdziesz coś takiego jak po:

SELECT * FROM "posts"
INNER JOIN "post_connections" ON "posts".id = "post_connections".post_b_id
WHERE ("post_connections".post_a_id = 1 )

Aby Asocjacja była dwukierunkowa, musielibyśmy znaleźć sposób na odwrócenie powyższych warunków za pomocą post_a_id i post_b_id, aby wyglądało to w obu kierunkach.