Potential cursor pagination bug with hasPrevPage
and hasNextPage
#5154
Replies: 3 comments 3 replies
-
@B4nan Hi. Not sure if you saw this or not but I would love to hear your thoughts on it. Thank you! |
Beta Was this translation helpful? Give feedback.
-
The That being said the third query feels weird to me: if |
Beta Was this translation helpful? Give feedback.
-
This is being implemented right now: #5320 |
Beta Was this translation helpful? Give feedback.
-
Hello, I'm testing out the new cursor pagination in v6 (using 6.0.4) and I've encountered a potential bug. It might be intended but I think it should probably be changed even if it is intended.
I made a reproduction here: https://github.com/stefansundin/mikro-orm-reproduction/tree/cursor-hasPrevPage-hasNextPage-bug
The problem is when you are paginating "backwards" with
last
andbefore
, when you hit the "last" page (i.e. you arrive back at the "first" page),hasPrevPage
andhasNextPage
will be reversed from what you expect.Here's the relevant code from the reproduction:
I haven't used cursor pagination a ton in other ORMs or frameworks, so I don't know if this is how other projects work. But if it is intended then I would have to swap the booleans manually whenever I am paginating backwards.
As an attempt to see how others do it, I checked out how the GitHub graphql API works, and there it is behaving the way I expect. You can try this in their graphql explorer:
Here's the response I got:
In the last request,
hasPreviousPage
isfalse
andhasNextPage
istrue
, which makes sense.I am opening this as a discussion as it might be intended. I know v6 is brand new so the docs are not fully fleshed out on the details, but I think eventually some of this behavior should be documented here.
Thanks!!!
Beta Was this translation helpful? Give feedback.
All reactions