will_paginate, включает в себя и упорядочение по объединенной таблице - PullRequest
Новая
       15

will_paginate, включает в себя и упорядочение по объединенной таблице

2 голосов
/ 20 февраля 2012

Итак, я делаю что-то вроде: 

 user.students.includes(:exams).ungraded.paginate(:page =>
   params[:page]).order("exams.created_at desc")

Однако, это вызывает тонкую проблему.Где-то в кишках активной записи, предел делает его отличным от идентификатора студента, например: 

SELECT DISTINCT "students".id, exams.id AS alias_0 FROM "students" 
LEFT OUTER JOIN "exams" ON "exams"."student_id" = "students"."id"
WHERE "students"."ready_for_grading" = 't' ORDER BY exams.id LIMIT 10 OFFSET 0;

Однако это может привести к таким результатам: 

 id | alias_0 
----+---------
 42 |     256
 42 |     257
 42 |     260

См.эта проблема?В конечном счете, ограничение вступает в силу, и мы не получаем столько идентификаторов учеников, сколько предполагалось, потому что мы «использовали их», выбирая идентификаторы учеников и экзаменационные, даже если мы действительно хотим, чтобы идентификаторы экзаменовordering.

Это Rails 3.2.1 и PostgreSQL 9.1.

Edit

Я думаю, что происходит, когда paginate использует запросчтобы получить список студентов, который он затем передает во второй запрос, но из-за левого внешнего соединения мы не получаем отчетливых результатов для студентов, поэтому он «недооценивает» 10 имеющихся у нас слотов и, как правило, приводит к путанице.Я думаю, что это где-то ошибка, но я не уверен, к кому ее можно прикрепить.

1 Ответ

5 голосов
/ 15 июня 2012

Хорошо, я наконец понял это: 

user.students.joins("left outer join exams on exams.student_id = students.id").ungraded.paginate(:page =>
   params[:page]).order("exams.created_at desc")

Кажется, работает.Я не уверен, почему это работает лучше, чем использование include, но это так.

...