-
-
Notifications
You must be signed in to change notification settings - Fork 7k
Warn about importance of ordering for all pagination classes #8494
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
The ordering recommendations given for the CursorPagination scheme actually apply to all pagination schemes, an unsuspecting developer that implements the more common `LimitOffsetPagination` or `PageNumberPagination` classes is unlikely to be aware of the importance of consistent ordering. This commit moves the `Details and limitations` section out of the `CursorPagination` section and puts it as the very first subsection of the `Pagination` page so that it's one of the first things that developers see. Some examples of inconsistencies as well as how to deal with them are given, and an extra way to change the ordering of a paginated view is provided. Fixes encode#6886
I'm not convinced that this section makes sense when moved around like this.
For example from a first look over - it discusses the ordering attribute on the pagination class. Which is specific to the CursorPagination class, rather than being generally applicable.
You're right, when I wrote this patch I hadn't actually tried to implement CursorPagination yet so I assumed some of these things also applied to the other Pagination classes (like an interface).
I have made some changes, I kept it as a general section because the only Pagination class that is really different from the others is CursorPagination, so having a subsection per class seemed like a lot of duplicated text.
Faki-140386
commented
Jun 7, 2022
Segue sempre sem fazer nenhuma alteração
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.
@tomchristie any chance of ever getting something like this merged? I feel like it's an easy and dangerous trap to fall into
@tomchristie any chance of ever getting something like this merged? I feel like it's an easy and dangerous trap to fall into
did you addressed the concerns @tomchristie initially raised?
@auvipy Well there was only one concern which was about the ordering attribute of the CursorPagination class which I did address, you can see the changes I made in the second commit (can be squashed).
If there are any other concerns I'm willing to address them too
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it would be better to include for elaborate code example here including the pagination classes
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.
Still looks relevant.
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.
The ordering recommendations given for the CursorPagination scheme
actually apply to all pagination schemes, an unsuspecting developer that
implements the more common
LimitOffsetPaginationorPageNumberPaginationclasses is unlikely to be aware of the importanceof consistent ordering.
This commit moves the
Details and limitationssection out of theCursorPaginationsection and puts it as the very first subsection ofthe
Paginationpage so that it's one of the first things thatdevelopers see.
Some examples of inconsistencies as well as how to deal with them are
given, and an extra way to change the ordering of a paginated view is
provided.
Fixes #6886
Hopefully this will prevent future developers from scratching their head and wondering why despite a view returning a count of X, going through all the pages yields Y records.