Open mattalbr opened 2 years ago
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 graphene-sqlalchemy
.
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 Connection
, etc with the official strawberry.relay
ones?
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).
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