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.
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
Add support for pagination at table level. #1244
Add support for pagination at table level. #1244
Changes from 12 commits
99551fc
5671955
9794af7
d958396
bcc7085
4dac677
635dcd6
f4ca7ec
0d14f11
15bcf49
34c4292
9b37c5a
6bea2ce
5e21036
d1ee4e0
f197ad1
8f971ab
e8bbace
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
Ideally, we'd have a check that if page is set, then orderBy must contain eventId. Can you add a TODO for now?
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.
Done!
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.
Ensure that the
limit
is only applied whenpage
is not provided to avoid unintended data truncation.Committable suggestion
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.
The comment about removing sorting is misleading because the sorting is actually necessary for consistent pagination results. Recommend rephrasing or removing this comment to avoid confusion.
Committable suggestion
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.
Question: How does this logic interact with additional items being added that are higher in the sort order than items returned?
E.g.
I want fills created after height X in descending order, page size of 10. I get page 2, which is the 10th-20th most recent fills. 10 new fills get added, and now I get page 3, would that be the same set of fills I got for page 2?
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.
To address your example: yes, you are right.
We use offset-based pagination to improve UX through parallel data retrieval, recognising the potential for data inconsistencies with new insertions. While this method provides fast access to any data segment, in certain scenarios it can lead to duplicate entries if data is added between two queries.
Conversely, cursor-based pagination offers better data consistency by using a pointer (cursor) to retrieve data sequentially, eliminating duplicates or missed entries due to data movement. However, it lacks the flexibility of parallel retrieval and direct access to specific data segments.
The request for such a feature stems from the need to add pagination to retrieve a user's full trading history at the front-end.
Given the frequency of data updates relative to request receipt in our context, we believe that offset-based pagination strikes the best balance for our current needs, optimising the user experience while considering the trade-off in data consistency. In fact, in this scenario, if a user has a very long history, a sequential approach could actually degrade the user experience, as we would have to wait for each request to continue with the new one.
Anyway, give us more feedback, we are open to adapting our approach as requirements evolve.