-
-
Notifications
You must be signed in to change notification settings - Fork 27
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
Support relay-style pagination (e.g. via sqlakeyset) #5
Comments
I think this could be an interesting idea, and if you think it would be helpful, you should give it a go! How would you handle the assumptions? Would you assume the same constraints as sqlakeyset? Or is there room for more flexibility here? We could also start off with something basic that solves most of the problem as that may be better than doing everything by hand. |
Hi! Thanks for your great work on this project ! I'm very interested in pagination too, and I got a working fork with pagination/sub pagination support (using this sqlakeyset fork). My fork is currently embedded in another project and needs a bit of refactoring to be extracted, I will open a PR when it's ready. |
Here is my fork with relay pagination. Note that I'm using sqlalchmy 2.0 style only and everything is async, so it's not backward compatible with the current codebase. |
@gazorby looks really nice! I think that would bring this library almost to feature-parity with |
That's great! If it were possible to add backwards compatibility, I'd be happy to review a pull request with the change. |
@mattalbr Would you be open to a PR that started by swapping out the custom generated classes for |
Let me add in Thiago who is actually going to implement this feature for us. I'm open to it personally (though we'll need to do a bit of work with the whole GlobalID thing). |
This feature has been added on #65 ! |
sqlakeyset provides a neat library to do keyset-based pagination of sqlalchemy queries. I think it could be awesome if our generated connection types supported input (first, after, last, before, order, condition) and we autogenerated pagination, ordering, and filtering support. The tricky part would be some of the assumptions built into sqlakeyset (you almost always need to sort it by some primary key if the values that you're sorting aren't unique, it doesn't support sorting on nullable fields unless you coalesce them, it doesn't support sqlalchemy 2.0-style queries).
What do you think? How would you feel about this feature if someone were to implement it? With something like this, the mapper becomes really powerful and magical right off the bat, and could conceivably be used to solve real-world problems with minimal customization. As is, I have to implement every list-based relationship by hand to deal with pagination and filtering, which is a bummer. Not the end of the world, just seems like something the mapper could do on its own.
Upvote & Fund
The text was updated successfully, but these errors were encountered: