I meant to imply we should improve our UDT usability to support this kind of
querying, essentially β but that if we support a simple text->property setup we
might want to offer LIKE support so we can search them (via simple filtering,
not any index) β which is actually pretty easy to provide.
I think we should aim to provide users all the facilities they need to interact
with config via vtables. If the user requires external tooling, it suggests a
weakness in CQL that we should address, and maybe help the user in other
scenario tooβ¦
From: Joseph Lynch <joe.e.ly...@gmail.com>
Date: Monday, 29 November 2021 at 17:32
To: dev@cassandra.apache.org <dev@cassandra.apache.org>
Subject: Re: [DISCUSS] Nested YAML configs for new features
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
