Rails Mongoid & Kaminari query in view
现在用 Mongoid 2.3.4 ,Kaminari 做分页 一般场景： controller
def index
@products = Products.all.page(params[:page])
end
view
- @products.each do |product|
= product.name
= paginate @products
这样的话，实际的查询是在@products.each这里执行的，这个算 Query in view 不？
如果换成 controller
def index
@criteria = Products.all.page(params[:page])
@products = @criteria.execute
end
view
- @products.each
- xxxxx
= paginate @criteria
速度会快一些，但觉得比较蹩脚，每个用到分页的地方都要这样了。。 各位有什么建议不
就是这样啦，所谓不要 Query in view 是指逻辑，不是执行。
rails 3.1 的 stream 正需要延迟查询。在 action 里面 execute 不会使速度边快，只是查询耗时从 view 里面移到 action 而已。
那么我有点迷惑了 1.（实际的 query 在 view 中执行） controller
def index
@products = Products.all.page(1)
end
view
- @products.each do |p|
- xxxx
2.（实际的 query 在 controller 中执行） controller
def index
@products = Products.all.page(1).execute
end
view
- @products.each do |p|
- xxxx
3.（实际的 query 在 view 中执行） controller
def index
end
view
- Products.all.page(1).each do |p|
- xxxx
在速度上有区别吗？(我这里测下来差不大) @xdite 在 blog http://wp.xdite.net/?p=3063 中提到真正速度緩慢的元兇是：Query in View。 我这个例子中有导致缓慢的 Query in view 吗？ 另外：如果 Query in view 是指逻辑，那么就应该不会影响速度了啊？？ 求解
这本身是推荐的用法，跟 3.0 之前比，这样做还有额外好处。
比方说，如果你在 view 上有 fragment cache，因为 action 中的查询执行只在 view 上的 collection.each 上才展开，如果这部分放在 fragment cache 中，只有当缓存失效（或不存在）时才会去执行。
跟以前相比，省去了在 action 中做 fragment cache 是否已经存在的判断。
当 db 查询是瓶颈时，view 上的一点时间往往可以忽略。反过来，当 render view 比 DB 慢很多时，就要想办法在 view 上做优化了，如：
(Views: 633.1ms | Mongo: 23.5ms)
