-
Notifications
You must be signed in to change notification settings - Fork 18
Please provide more flexible gql querying #25
Comments
I'm happy to help design individual query, but there's a limitation inherent with OR and NOT_EQ queries which I can't fix. There are good talks and articles describing why this isn't a feature supported in big-data databases and whey they are inherently slow. There should otoh always be a way to query the data in alternative kind of fashion that you get what you are looking for. Ranges are supported (height min height max in blocks query as example), contains is also possible ex. providing list of ids. But each way of querying requires enormous amount of time in design. In any case, some feature could be missing which we can support from the list of contrains you mentioned. If we find the highest priority queries we need to support, we'll work on support for them one by one, then I think we are on a good track, knowing that still, it's a lot of work making fast queries with huge amount of data (which is getting exponentially bigger these days). |
Currently all queries are effectively AND queries. We need to have things like OR, Contains, Greater than or Less Than, Starts With, Ends With, Not Equal, Ranges, etc.
This is hard but for some workflows really necessary. Perhaps start with Contains and Greater Than and Less Than?
The text was updated successfully, but these errors were encountered: