t this work will go to 5.0 only.
> > > I am not completely sure it is necessary to backport this feature but
> > > your argumentation here (2) is worth to discuss further.
> > >
> > > If we introduce this change to 4.1, that fiel
s an
> > > interesting proposal. I was thinking that this work will go to 5.0 only.
> > > I am not completely sure it is necessary to backport this feature but
> > > your argumentation here (2) is worth to discuss further.
> > >
> > > If we int
worth to discuss further.
> >
> > If we introduce this change to 4.1, that field would not be there but in
> > 5.0 it would. So that way we will not introduce any new column to
> > system_views.settings.
> > We could also go with the introduction of this column to
s.settings.
> We could also go with the introduction of this column to 4.1 if people are ok
> with that.
>
> For the simplicity, I am slightly leaning towards introducing this feature to
> 5.0 only.
>
> (1) https://github.com/apache/cassandra/pull/2334#discussion_r1251104171
>
ing this feature
>> to 5.0 only.
>>
>> (1) https://github.com/apache/cassandra/pull/2334#discussion_r1251104171
>> (2) https://github.com/apache/cassandra/pull/2334#discussion_r1251248041
>>
>>
>> From: Maxim Muzaf
;
> From: Maxim Muzafarov
> Sent: Friday, June 23, 2023 13:50
> To: dev@cassandra.apache.org
> Subject: Re: [DISCUSS] Allow UPDATE on settings virtual table to change
> running configuration
>
> NetApp Security WARNING: This is an external em
Re: [DISCUSS] Allow UPDATE on settings virtual table to change running
configuration
NetApp Security WARNING: This is an external email. Do not click links or open
attachments unless you recognize the sender and know the content is safe.
Hello everyone,
As there is a lack of feedback
Hello everyone,
As there is a lack of feedback for an option to go on with and having
a discussion for pros and cons for each option I tend to agree with
the vision of this problem proposed by David :-) After a lot of
discussion on Slack, we came to the @ValidatedBy annotation which
points to a
Hello everyone,
I want to continue this topic and share another properties validation
option/solution that emerged from my investigation of Cassandra and
Accord configuration that could be used to make the virtual table
SettingTable updatable, as each update must move Config from one
consistent
Hello everyone,
It seems to me that we need another consensus to make the
SettingsTable virtual table updatable. There is an issue with
validating configuration properties that blocks our implementation
with the virtual table.
A short example of validating the values loaded from the YAML file:
experience whenever we wanted to generate something we had to take care
> >> of the generator itself and then we had to live with what it generated
> >> (yeah, that is also a thing) instead of writing it by hand once and have
> >> some freedom to tweak it however we
ed. Splitting this into the second class
>> ... well, I would say that just increases the entropy.
>>
>> We can parse config class on these annotations and produce the documentation
>> easily. I would probably go so far that I would put that annotation on all
>> field
rch 1, 2023 9:09
> To: dev@cassandra.apache.org
> Subject: Re: [DISCUSS] Allow UPDATE on settings virtual table to change
> running configuration
>
> NetApp Security WARNING: This is an external email. Do not click links or
> open attachments unless you recognize the sender and
. We could have two - Mutable, and Immutable. But that is really optional.
From: Benedict
Sent: Wednesday, March 1, 2023 9:09
To: dev@cassandra.apache.org
Subject: Re: [DISCUSS] Allow UPDATE on settings virtual table to change running
configuration
NetApp
Another option would be to introduce a second class with the same fields as the first where we simply specify final for immutable fields, and construct it after parsing the Config.We could even generate the non-final version from the one with final fields.Not sure this would be nicer, but it is an
I agree with David that the annotations seem a bit too many but if I have
to choose from the three approaches - the annotations one seems most
reasonable to me and I didn’t have the chance to consider any others.
Volatile seems fragile and unclear as a differentiator. I agree
On Tue, 28 Feb 2023
Folks,
If there are no objections to the approach described in this thread,
I'd like to proceed with this change. The change seems to be valuable
for the upcoming release, so any comments are really appreciated.
On Wed, 22 Feb 2023 at 21:51, David Capwell wrote:
>
> I guess back to the point of
I guess back to the point of the thread, we need a way to know what configs are
mutable for the settings virtual table, so need some way to denote that the
config replica_filtering_protection.cached_rows_fail_threshold is mutable.
Given the way that the yaml config works, we can’t rely on the
Could you describe the issues? Config that is globally exposed should ideally be immutable with final members, in which case volatile is only necessary if you’re using the config parameter in a tight loop that you need to witness a new value - which shouldn’t apply to any of our config.There are
Could maybe be an issue for some really tight unit tests. In actual use the
updates to those fields will be globally visible near instantly without
volatile keyword.
> On 22 Feb 2023, at 13:17, Benjamin Lerer wrote:
>
> I have seen issues with some updatable parameters which were missing the
I have seen issues with some updatable parameters which were missing the
volatile keyword.
Le mer. 22 févr. 2023 à 11:36, Aleksey Yeshchenko a
écrit :
> FWIW most of those volatile fields, if not in fact all of them, should NOT
> be volatile at all. Someone started the trend and most folks have
FWIW most of those volatile fields, if not in fact all of them, should NOT be
volatile at all. Someone started the trend and most folks have been copycatting
or doing the same for consistency with the rest of the codebase.
Please definitely don’t rely on that.
> On 21 Feb 2023, at 21:06, Maxim
Hello everyone,
I would like to share and discuss the key point of the solution design
with you before I finalise a pull request with tedious changes
remaining so that we are all on the same page with the changes to the
valuable Config class and its accessors.
Here is the issue I'm working on:
23 matches
Mail list logo
