Search pager refactoring needed #429

mworrell opened this Issue Sep 28, 2012 · 2 comments


None yet
3 participants

mworrell commented Sep 28, 2012

Currently we still use a hack to calculate the number of search results. This was placed somewhere in 2009 when we had to release.

We need to add a real way to support the pager, especially with our growing databases.

Just calculating the exact number of results is not doable when you have a lot of results and want to stay fast.

Though here is a solution mentioned (in the comments):

I propose a strategy where we don't know the number of results, but do know if there are more than the ones we fetched.


  • Select the page we want using limit/offset

  • Add some extra pages to the limit

  • Check how many results we got back:

    • If we got the limit results, unset as is_complete flag
    • If we got less, set the is_complete flag

    In both cases recalculate the number of expected pages.

The pager would then look something like:

[1] [2] [3] ... [more]

Please some feedback.

We could use the exact calculation method if the is_exact_page_count flag is set as an argument to the query (like the page and page length args)


ArthurClemens commented Aug 26, 2015

@mworrell Is this still relevant?


ddeboer commented Jan 12, 2016

See also #599 and #1025.

ddeboer referenced this issue Nov 30, 2016


core: Support custom search total #1537

1 of 1 task complete

@ddeboer ddeboer modified the milestone: 1.0, Roadmap May 31, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment