The client currently uses LIMIT and SKIP conventions to paginate results. The latest convention uses a returned cursor to paginate through result sets instead. This should increase the overall speed of pagination for large result sets.
I took a non-breaking approach to this update. If the user does not supply limit or skip parameters then the new cursor functionality will be used.
Please let me know if I missed any requirements or expectations for this PR, thank you!
Testing
[x] This change adds test coverage for new/changed/fixed functionality
I have added tests and modified existing tests to differentiate between the two potential code flows: pagination with limit and skip and cursors. This has also been verified against the real J1 backend.
Checklist
[x] All active GitHub checks for tests, formatting, and security are passing
[x] The correct base branch is being used, if not master
Description
The client currently uses
LIMITandSKIPconventions to paginate results. The latest convention uses a returnedcursorto paginate through result sets instead. This should increase the overall speed of pagination for large result sets.I took a non-breaking approach to this update. If the user does not supply
limitorskipparameters then the newcursorfunctionality will be used.Please let me know if I missed any requirements or expectations for this PR, thank you!
Testing
[x] This change adds test coverage for new/changed/fixed functionality
I have added tests and modified existing tests to differentiate between the two potential code flows: pagination with
limit and skipandcursors. This has also been verified against the real J1 backend.Checklist
master