Open alexstandiford opened 4 years ago
There's a fair amount of filtering in Query
now that may make what I'm talking about possible, albeit in a different fashion.
This makes a ton of sense!
I would love it if how the \Queries\
classes are used was abstracted out, into something that could just be registered, looped through, built-up, hooked in, and then parsed.
They are all starting to be similar enough now, where I think those patterns are emerging.
I am a big +1 on this.
Resolving this issue requires #36 to be resolved first.
Marking this as a Task because it definitely should happen; the sooner the better.
WIP PR: #60
It would be really useful if it was possible to register different query processors into the
Query
class, similar to theDate
class that exists now. This would allow plugin developers to seamlessly inject their own query extensions into the query class, and provideQuery
with the instructions necessary to run the query.It would also give us a clear path on how to improve, and expand on BerlinDB's query functionality in the future. I'm thinking about issues like #50.
Right now, items like
Date
have to be hard-coded directly into the class to work, which obviously isn't ideal.Another thing that would be nice about this, is when contributing to BerlinDB, pre-made libraries can be added, and even pitched to be put into core. This gives everyone a relatively easy way to test, and try out a new feature without needing to completely replace their installation of BerlinDB just to make it work.