-
Notifications
You must be signed in to change notification settings - Fork 807
Description
I've just noticed this, when having both kaminari and will_paginate included in a project, elasticsearch-rails selects kaminari always in favor of will_paginate.
This prioritization occurs at this line:
I've opened this as an issue due to problems when paginating elasticsearch results without actually having the pagination to work, and without any errors being thrown either. The actual problem we had was caused with RailsAdmin requiring Kaminari and the pagination for elasticsearch results not working because we were trying to use will_paginate's methods (but no errors were thrown).
in order to solve the issue at the moment, as a workaround, one can include the will_paginate module which will effectively solve the issue but will leave some pollution with the kaminari methods still there.
# add this to solve, make sure you load this code after elasticsearch-rails loads
Elasticsearch::Model::Response::Response.__send__ :include, Elasticsearch::Model::Response::Pagination::WillPaginate
Of course, the Kaminari methods can be undefined by using remove_method or undef_method cycling through the already included module and such... but as a cleaner solution, giving the opportunity to choose the pagination library (at setup/config time) could help in avoiding these hard to track problems (or even, not requiring any integration by default, so that the developer is forced to make a conscious decision).
Thanks to @johaned for taking some time to track down this with me. Hope this issue helps overcome pagination not working (and not throwing errors) in some scenarios. I read about a possible related issue here: #239.
I am filing this so that any future developers (including myself!) with this same strange issue can have a workaround (if they ever encounter this).
Thanks!