Rails Mongoid & Kaminari query in view

niedhui · 2011年12月05日 · 最后由 huacnlee 回复于 2012年02月04日 · 3776 次阅读

现在用 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 楼 @Rei thanks 在 action 里面 execute 不会使速度边快,只是查询耗时从 view 里面移到 action 而已 确实

Products.all不是返回数组了吗?

那么我有点迷惑了 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 是指逻辑,那么就应该不会影响速度了啊?? 求解

哦,是我没理解 @xdite 的意图。我也做个测试看看。根据评论所说,是 eval 导致速度慢。


我在页面加了个查询,没感觉有啥差异

#3 楼 @doitian Mongoid 的 all 还是返回 Mongoid::Criteria

这本身是推荐的用法,跟 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)

很久没用过 ActiveRecord 了,不知道 3.1 里面的 ActiveRecord 查询方式是否和 Mongoid 的一样

需要 登录 后方可回复, 如果你还没有账号请 注册新账号