On Mon, Nov 29, 2021 at 11:51 AM bened...@apache.org
<bened...@apache.org> wrote:
>
> Maybe we can make our query language more expressive 😊
>
> We might anyway want to introduce e.g. a LIKE filtering option to
> find/discover flattened config parameters?
This sounds more complicated than just having the settings virtual
table return text (dot encoded) -> text (json) and probably not even
that much more useful. A full table scan on the settings table could
return all top level keys (strings before the first dot) and if we
just return a valid json string then users can bring their own
querying capabilities via jq [1], or one line of code in almost any
programming language (especially python, perl, etc ...).
Alternatively if we want to modify the grammar it seems supporting
structured data querying on text fields would maybe be more preferable
to LIKE since you could get what you want without a grammar change and
if we could generalize to any text column it would be amazingly useful
elsewhere to users. For example, we could emulate jq's query syntax in
the select which is, imo, best-in-class for quickly querying into
nearest structures. Assuming a key (text) -> value (json) schema:
'a' -> "{'b': [{'c': {'d': 4}}]}",
SELECT json(value).b.0.c.d FROM settings WHERE key = 'a';
To have exactly jq syntax (but harder to parse) it would be:
SELECT json(value).b[0].c.d FROM settings WHERE key = 'a';
Since we're not indexing the structured data in any way, filtering
before selection probably doesn't give us much performance improvement
as we'd still have to parse the whole text field in most cases.
-Joey
[1] https://stedolan.github.io/jq/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org
