-
Notifications
You must be signed in to change notification settings - Fork 12
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
Filtering: better "read" fns #120
Comments
Using the read() function to fetch a record with a specific primary key is a good-enough use case, so perhaps another option is to remove the paginate() fn? |
i would likely be in favor of removing |
Perhaps we can put them behind a feature flag and keep them in experimental/unstable state |
that would also be a option, should it be a default though? and if disabled, should the old code be generated? |
Yeah, let’s leave it disabled by default. That is to say: in the current version, this would only generate the paginate fn if some |
so if i understand correctly, we will remove the |
See #126 -- removed .paginate from default set and also introduced some experimental API behind |
I just wanted to share my thoughts on the 'read/paginate' functions:
They are very arbitrary unless we introduce a way to filter the results.
In #103, I attempted to add filter() helper which allows us to generate arbitrary WHERE clauses; however, it currently only supports "equals"-based clauses, and not things like:
This is a major turning point for
dsync
which has primarily been a code-generation tool as opposed to a query-builder. Deciding to add filter() is the only way functions like read() and paginate() make sense. However, we can only go so far with the filtering before we end up with a query builder 😅.So here's the thing: do we continue with this effort?
Some more thoughts: we should consider generating cursor-based pagination functions and may also want to split
read
into:read_first
andread_all
(or similar-named functions).Anyway, no big deal, hope all is well 🙌
The text was updated successfully, but these errors were encountered: