New Pagination class as an alternative to CursorPagination #9504
Unanswered
hashim-uptick
asked this question in
Ideas & Suggestions
Replies: 1 comment
-
PK as a tiebreaker is a good approach. We do specify "Orderings should be unchanging, unique or nearly unique". Perhaps a docs improvement is appropriate here? For example |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
The current CursorPagination class works exactly as specified, but it seems that people -- my workplace included -- often try to use it in a way where it isn't supposed to be used.
Our example was one where CursorPagination was used on a view with multiple columns being used for ordering. Because the first column was a boolean, something like
is_active
, and had thousands of matches, theoffset
part of the cursor and the page size interacted in a way that the next links started looping.offset
was 1500, got reduced by the cutoff logic to 1000, page size 500 was added, new offset became 1500 again, hence loop.I found other discussions of people reporting more use cases where cursor pagination was either buggy or did not fit:
Especially as in discussion 9373 a fix would be a breaking change, would the maintainers be happy to accept a new pagination class into django rest framework?
We implemented one where the primary key is used as a tiebreaker and to ensure that the ordering is deterministic, we can contribute it here. We also made it more robust against the result set being mutated as someone is paging through it.
Something like
UniqueCursorPagination
that leverages some unique constraint in the models -- eg the primary key, or evenPkUniqueConstraint
that's specific to using primary keys -- and solves for all the above use cases.Beta Was this translation helpful? Give feedback.
All reactions