queries with q= #877
Replies: 5 comments 4 replies
-
|
adding prior art (v1) - https://github.com/ctron/sikula/ |
Beta Was this translation helpful? Give feedback.
-
|
After various conversations:
before we answer the above might be useful to get clarification/direction from product peoples ... @mid998 |
Beta Was this translation helpful? Give feedback.
-
|
IMO we need to separate things: I mean, separate the "query abstraction system" (this is the WHAT) from the "implementation of the query system" (this is the HOW) as they are 2 different things independent from each other.
What I am trying to say is that Design vs Implementation, where is the problem (perhaps both?)? And then yeah, why not, this can be reevaluated. Just my two cents. |
Beta Was this translation helpful? Give feedback.
-
|
thx completely agree with your observations. We have a mixture of things and unclear if we are hitting requirements ... when I say requirements I mean 2 buckets - what ux web devs need and what end users need. Requirements->Design->Impl |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, I agree. As for requirements, I believe UX+PM+the help of enginering need to define which filters (as filters will use the http query language) we need to implement in the UI and that might partially cover some requirements. I have just created this document for discussing Filters with UX and PM. But not sure how long it is going to take until we define which filters we need. |
Beta Was this translation helpful? Give feedback.
-
|
I think there's a little bit more than just UX. What do "API users" need? |
Beta Was this translation helpful? Give feedback.
-
We definitely support multiple filters using the Will that not work for you? |
Beta Was this translation helpful? Give feedback.
-
|
thx it does work for me - I thought I did this ..... in any event we still need to boil down requirements @carlosthe19916 doc goes through ... at first glance I think what we have today might be enough ... though want to flush out any gigantic requirements (like full blown query language). |
Beta Was this translation helpful? Give feedback.
-
|
unless I am mistaken, I think what we have currently is sufficient ... the graphql is a separate concern ... going to close this discussion |
Beta Was this translation helpful? Give feedback.
-
Recently I have been reviewing common/src/db/query.rs to see how we might extend it to be able to query jsbonb columns and have a few observations.
The first is that query.rs and subsequent usage of ?q= does not provide any way of using multiple filters ... of course overloading all query params into a single url param means the following is not possible to parse:
one might argue that whatever separator we may use - like the comma here
are awkward compared to:
Or maybe when q='' is quoted we can then parse whats in it ? or maybe this works and I am being stupid ;)
Is it time to consider adding well known filters ?
Do we need to support a fully generic approach or is it good enough to provide specific filters for operators other then equivalence ? For example
could be explicitly
With tradeoffs in every direction - not sure what the right answer is and soliciting broader opinion.
Beta Was this translation helpful? Give feedback.
All reactions