Sort option is ignored with kaminari

[DSalko]

Hello

I'm trying to use ES sort option like

 @results = self.search( { 
                  :query => {
                        ....
                      } 
                   } ) , 
                  :sort => [
                    { :created_at => :desc }
                  ] } )

and paginate results like this with Kaminari gem

@results.page( page ).per(50).records

And appears that :sort option doesn't affect results at all. I'm also using Mongoid. Any suggestions?

Thanks.

[karmi]

I've added an integration test in 354b25a, and it works for me for ActiveRecord... Can you try a similar test/code with Mongoid? Also, might be different on ActiveModel/Mongoid versions 3 and 4...

[DSalko]

Thanks for such a quick reply. So far, I think the order gets ruined during .records operation which queries mongo with [$in] operator. I'll let you know when I have more certain results about this.

Thanks again, you rock!

[DSalko]

Small update on this, looks like that adding @results.page( page ).per(50).records.to_a fixes ordering issue.

[karmi]

@DmitriySalko Hmm, to_a shouldn't "fix" anything, since it's called for any each, first you do on the collection.

[netwire88]

I have the same problem running Mongoid v3. The to_a suggestion didn't work.

[DSalko]

I have mongoid (4.0.0) and to_a seems like a workaround, but I still want to do more tests to be sure.

[michaelherold]

I'm seeing the same behavior with mongoid-4.0.0, kaminari-0.15.1, and elasticsearch-[rails|model]-0.1.6.

Returning the results as @results.page(page).per(10).records ignores the sorting, whereas @results.page(page).per(10).records.to_a correctly sorts the result.

[JamesHarrison]

We just hit this issue with Mongoid, Kaminari and es-rails - in (re)tire it appears that the preservation of search result ordering is done on the (equivalent) records call if the records are loaded (see https://github.com/karmi/retire/blob/master/lib/tire/results/collection.rb#L149), but in elasticsearch-rails/model this isn't the case.

[karmi]

The to_a is important -- when you see the code of the adapters, that is the place where the re-ordering of records (based on order of results) is being done.

@JamesHarrison Can you be more specific? I'm getting lost in the discussion :)

[JamesHarrison]

Specifically, Kaminari (and I assume other paginators) assume you're passing in the records object, along with associated metadata about number of pages of results, total max results, etc. While you can pass Kaminari a raw array it's not the recommended way to use it. Having to call to_a in order to get the results back sorted means Kaminari doesn't get sorted results, because it doesn't call to_a as it can just enumerate results directly off the returned records.

In Tire, if you called .results you got a sorted set of results without any further calls. Monkeypatching es-rails to do the same doesn't appear to cause any issues, and I'm not sure why the sorting code should be isolated and only called on to_a in es-rails

[salimane]

any update on this ?

[ain]

Reproduced on PostgreSQL. to_a did not resolve.

[pacuna]

I had the same issue with MySQL. I was applying a random score function and it was being ignored. I added to_a and then it worked.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.