le release as opposed
>> to rolling it to the next release.
>>
>> Thanks,
>> German
>>
>>
>> *From:* Maxim Muzafarov
>> *Sent:* Wednesday, May 29, 2024 1:09 PM
>> *To:* dev@cassandra.apache.org
>> *Subject:* [EXTERNAL] Re: [DISCUSS] Adding exp
uding it into a stable release as opposed to
> rolling it to the next release.
>
> Thanks,
> German
> From: Maxim Muzafarov
> Sent: Wednesday, May 29, 2024 1:09 PM
> To: dev@cassandra.apache.org
> Subject: [EXTERNAL] Re: [DISCUSS] Adding experimental vtables and rules
&g
experimental vtables and rules around
them
Hello everyone,
I like the idea of highlighting some of the experimental virtual
tables whose model might be changed in future releases.
As another option, we could add an @Experimetal annotation (or another
name) and a configuration parameter
The two-part proposal of 1.) table-level self-identification of
experimental status and 2.) a global config flag that determines what to do
when querying those might work. I guess the only thing you can't do there
is ignore warnings from a specific experimental table, since that's
controlled in cod
> As another option, we could add an @Experimetal annotation (or another name)
> and a configuration parameter experimental_virtula_tables_enabled
Since these are tables we have TableProps so we could always store an
experimental = true there and if Config.experimental_virtula_tables_enabled ==
I think that 2) (client warning on accessing vtable) is pretty obtrusive /
irritating, that means that every single time I would e.g. SELECT from such
a table, it would emit a warning to a client / cqlsh? I do not think that
is necessary.
What about putting such a table to system_experimental keys
Hello everyone,
I like the idea of highlighting some of the experimental virtual
tables whose model might be changed in future releases.
As another option, we could add an @Experimetal annotation (or another
name) and a configuration parameter
experimental_virtula_tables_enabled (default is false
I agree that ClientWarning is the best way to indicate the risk of using an
experimental feature directly to the user. Presenting information in the client
application's logs directly means that the person who wrote the query is most
likely to see the warning, rather than an operator who sees cl
We agreed a long time ago that all new features are disabled by default, but I
wanted to try to flesh out what we “should” do with something that might still
be experimental and subject to breaking changes; I would prefer we keep this
thread specific to vtables as the UX is different for differe
