Kaminari not paging my records

[mariochavez]

Hi;

Inside of my index action I have something like
@shipments = Shipment.order('date desc').page(params[:page])

If page is null, not passing the parameter or page == 1 then I got results and my @shipments variable get loaded, but if page >= 2 I got nothing, actually looking at Rails log no query is being issue.

My shipments table have hundred of records.

If I try the exact same line of code in Rails console it works, it issue the query

I'm using version 0.10.4 of kaminari.

Do you have any suggest on how to fix this?

[alexistoulotte]

This is due to OFFSET and LIMIT in count query. Have a look to your logs: SELECT COUNT(*) FROM "table" LIMIT x OFFSET x. There is other issues tickets about it. I'll try to provide a patch.

[mariochavez]

alexistoulotte;

Yeah I found other tickets with the same issue, for now I'm using the .all.count workaround and is working.

Thanks

[alexistoulotte]

IMHO .all.count is absolutely not a solution: if you have 10 000 records, it fetch and instanciate all of them.

[amatsuda]

@alexistoulotte

No, that is not true. Model.limit(10).offset(x).all fetches only 10 records.
And you're probably using all of these 10 records somewhere in the view anyway, so I think fetching them by all for count is not a very bad idea.

[mariochavez]

@alexistoulotte after calling .page(x) and .all.count, there is no other sql query, but my variable gets the expected objects from .page call.

I would like that only calling .page(x) could be enough to get my objects, but right now this allow me to use kaminari.

[alexistoulotte]

OK, after a .page(x) that's true, it only fetch 10 records. But I don't agree with you on other point. I ensure that .all in rails always performs an SQL query.

Note that the issue is due to scopes created by kaminari and count. count just can't work correctly while records are not fetched. That's not a kaminari issue. Here is an explanation:

articles = Article.page(42).per(10)
articles.count # 0 (because it generates makes a "SELECT COUNT(*) LIMIT x OFFSET x" query
articles.size # 0 (the same as count)
articles.empty? # true (because it uses count)
articles.any? # false (because it uses count too)
articles.all.size # 10 (but it fetches records)
articles.except(:limit, :offset).count # yeah, 142 (without fetching records)!
articles.total_count # same as before (kaminari internal)

You may figure that the solution is to invoke #all method before, but,... no:

articles = Article.page(42).per(10).all
articles.count # 10 (array method)
articles.total_count # NoMethodError (and required by view helper!).

A workaround for kaminari is to dynamically override #count (after invoking #page method) without limit and offset (exactly like total_count) in order to have #empty?, #any? with correct behavior.

WDYT?

[amatsuda]

Yes, I understand that AR .limit + .count is somewhat broken ATM.
Actually that problem is already reported as a bug on rails.lighthouseapp https://rails.lighthouseapp.com/projects/8994/tickets/5060

So, I suppose that would be improved sooner or later.

The best solution I found so far is this patch rails/rails#201
so I will try freedom patching .count method with this approach inside Kaminari.

Thanks!

[alexistoulotte]

OK, cool :)

Will monkey patch for the moment until next rails release.

Thanks!

[krzkrzkrz]

Experiencing the same issue. I am doing:

<% @comments.entries.each do |comment| %>

Instead of:

<% @comments.each do |comment| %>

Which seems to work for now. Please keep me posted as to when an official patch is realeased

[iwasinnamuknow]

I'm having problems with this. Kaminari is only showing the first page of results for me, "SELECT COUNT(*) FROM xxx LIMIT 25 OFFSET 25" in the logs. Running rails 3.0.6, kaminari 0.10.4. Heard good things about kaminari but this is really stuck for me. Hopefully there will be a good fix soon.

[amatsuda]

This is actually already fixed in edge Rails
rails/rails@d5994ee
rails/rails@28c73f0
but I guess these commits won't be backported to 3.0 branch.
So, I put a workaround for this in 0.11.0 gem 465a2d0

Let's see how this works...