Filtering: better "read" fns about dsync HOT 7 OPEN

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?

from dsync.

That is to say: in the current version, this would only generate the paginate fn if some experimental flag was set. If we want to stabilize parts of these experiments in the future, we’ll put them behind specific flags or add them to the default set, according to our decision

so if i understand correctly, we will remove the .paginate function from non-flag builds?

from dsync.

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?

from dsync.

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 .paginate (and related things in #103), unless we make it explicit that the default paginate function is meant to paginate without a specific clause (table order).
as for the other functions, i think it is reasonable to have some CRUD functions based on the identifier(s)

from dsync.

Perhaps we can put them behind a feature flag and keep them in experimental/unstable state

from dsync.

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 experimental flag was set. If we want to stabilize parts of these experiments in the future, we’ll put them behind specific flags or add them to the default set, according to our decision

from dsync.

See #126 -- removed .paginate from default set and also introduced some experimental API behind advanced-queries

from dsync.