will_paginate 包含重新排序结果
Rails 2.3.8 + will_paginate 2.3.14
我有 Product 和 ProductReview 模型。
Product
has_many :product_reviews, :dependent => :destroy
named_scope :most_recently_reviewed, :order => 'product_reviews.created_at desc', :include => [:product_reviews]
ProductReview
belongs_to :product, :counter_cache => true
运行带分页和不带分页的最基本查询会以完全不同的顺序返回项目。
Product.most_recently_reviewed.collect{|p| p.id }[0,9]
=> [1660, 1658, 2374, 578, 1595, 135, 531, 550, 1511]
Product.most_recently_reviewed.paginate(:page => 1, :per_page => 40).collect{|p| p.id }[0,9]
=> [1660, 2374, 578, 1711, 1855, 1730, 1668, 1654, 2198]
将 per_page 扩展为大于产品数量的数字会导致分页返回正确的结果：
Product.most_recently_reviewed.paginate(:page => 1, :per_page => 1000).collect{|p| p.id }[0,9]
=> [1660, 1658, 2374, 578, 1595, 135, 531, 550, 1511]
有什么建议吗？谢谢。
Rails 2.3.8 + will_paginate 2.3.14
I have both Product and ProductReview models.
Product
has_many :product_reviews, :dependent => :destroy
named_scope :most_recently_reviewed, :order => 'product_reviews.created_at desc', :include => [:product_reviews]
ProductReview
belongs_to :product, :counter_cache => true
Running the most basic query with and without pagination returns items in a completely different order.
Product.most_recently_reviewed.collect{|p| p.id }[0,9]
=> [1660, 1658, 2374, 578, 1595, 135, 531, 550, 1511]
Product.most_recently_reviewed.paginate(:page => 1, :per_page => 40).collect{|p| p.id }[0,9]
=> [1660, 2374, 578, 1711, 1855, 1730, 1668, 1654, 2198]
Expanding per_page to a number greater than the number of products causes paginate to return the proper results:
Product.most_recently_reviewed.paginate(:page => 1, :per_page => 1000).collect{|p| p.id }[0,9]
=> [1660, 1658, 2374, 578, 1595, 135, 531, 550, 1511]
Any suggestions? Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
分页的限制可能会应用于连接的结果，这些结果是具有多个产品评论数量的行。除了将范围标准移至分页调用（然后您可以将分页调用移至命名范围）之外，我还没有找到更好的解决方案。命名范围似乎不太适合 will_paginate。
Probably the limit from pagination is being applied to the results of the join, which are rows with multiplicity of the number of product reviews. I haven't found a better solution to this problem other than moving the scope criteria into the pagination call (you can then move the pagination call into the named scope). Named scopes just don't seem to work well with will_paginate.