[MODEL] Added functionality to provide custom value of total count for pagination #1023
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The Problem
When using collapse parameter to collapse search results, the total number of hits in the response indicates the number of matching documents without collapsing. As a result, the total number of pages for pagination is miscalculated.
Assume, for example, the following query on the
group_items
index returns a total of 100 results without collapsing.And when the search results are collapsed based on the
group_id
field value. The total results returned by the query becomes only 5 instead of 100.The problem occurs when we paginate results, after collapsing, the value of the total number of hits is still 100 in response, which results in the miscalculation of the total number of pages, as mentioned in the reference:
The solution
This problem with pagination can be solved by providing a custom value of
total_entries
(will_paginate) ortotal_count
(kaminari). The value of total distinct groups can be calculated by using cardinality aggregationNow to get pagination working correctly, the value of
total_count
can be specified.