Vor kurzem stieß ich mit Rails 4 und HABTM Beziehung auf mystische Fehler. vor allem mein Gemfile:
%Vor%Weiter. Meine Models:
%Vor%Raw DB-Daten:
%Vor%Endlich der Fehler:
%Vor%Wie Sie sehen, ist nur die erste Gruppe von Lehrern in der Sammlung zurückgekehrt. Allerdings ist SQL von Rails korrekt und gibt alle Daten zurück:
%Vor%Hat jemand schon einmal mit solchen Problemen zu tun gehabt? Ich kann nicht verstehen, was hier vorgeht.
P.S. Wenn Sie Resource.all.includes(:teachers).map { |r| r.reload.teachers } ausführen, ist das Ergebnis korrekt. Es entfernt jedoch Sinn von include und stellt N + 1 Problem.
UPDATE: Ein weiterer Fund wert, erwähnt zu werden. Wenn ich STI entferne funktioniert alles gut.
Ich habe diese ActiveRecord Modelle und Datenbankeinträge in Rails 4.1.6 mit pg gem neu erstellt und das korrekte Verhalten gesehen:
irb(main):017:0> Resource.all.includes(:teachers).map(&:teachers).map(&:to_a)
Resource Load (0.6ms) SELECT "resources".* FROM "resources"
SQL (6.9ms) SELECT "resources_users".*, "resources_users"."id" AS t0_r0, "resources_users"."resource_id" AS t0_r1, "resources_users"."user_id" AS t0_r2, "users"."id" AS t1_r0, "users"."type" AS t1_r1, "users"."created_at" AS t1_r2, "users"."updated_at" AS t1_r3 FROM "resources_users" LEFT OUTER JOIN "users" ON "users"."id" = "resources_users"."user_id" AND "users"."type" IN ('Teacher') WHERE "users"."type" IN ('Teacher') AND "resources_users"."resource_id" IN (1, 2, 3, 4)
=> [[#<Teacher id: 13, type: "Teacher", created_at: "2015-11-05 07:02:59", updated_at: "2015-11-05 07:02:59">], [#<Teacher id: 2, type: "Teacher", created_at: "2015-11-05 07:02:20", updated_at: "2015-11-05 07:02:32">], [#<Teacher id: 12, type: "Teacher", created_at: "2015-11-05 07:03:50", updated_at: "2015-11-05 07:03:50">], [#<Teacher id: 2, type: "Teacher", created_at: "2015-11-05 07:02:20", updated_at: "2015-11-05 07:02:32">]]
Gleiches Problem hier mit Rails 4.1.6 und pg , aber ich kann das richtige Verhalten erreichen, indem ich das Feld resources_users id in der Migration nicht lösche:
Auch funktioniert eager_load in beiden Fällen (mit oder ohne id in der Join-Tabelle) und Sie haben die Vorteile einer einzigen SQL-Abfrage:
Ausgabe:
%Vor%