[
https://issues.apache.org/jira/browse/CASSANDRA-15254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17687215#comment-17687215
]
David Capwell commented on CASSANDRA-15254:
-------------------------------------------
sorry, fat finger published comment before I finished, so split into 2 comments
=)
bq. My results of a comparison of a field name with the corresponding methods
name in camel case:
So, your matching works around 50% of the cases we support today? And this
under counts as it doesn't deal with legacy names or nested names... to me I
feel that this inference system is more problematic path to go down.
bq. I see now we have a good starting point for making the configuration
properties associated with the 35 JMX setter methods that fully match the
property name to make them available for modification by SettingsTable for the
first step, leaving the others for the next.
I think you and I took two different take away from your POC... my take away is
that the matching doesn't work and we have far more mutable settings than
found, so using it as a starting point feels wrong to me.
bq. A clear exposition rule for configuration property - if a property name and
its type match the corresponding method in the DatabaseDescriptor
(GuardrailsOptions), this means that the property can be modified by public
APIs;
I don't feel that this is "clear" as it doesn't deal with most of our
configs... a rule that matches a subset of configs is more arbitrary than
anything and very hard to maintain. This is also biased to forcing us to have
more boiler plate code than needed, so I question why would we want that? We
needed to have all this boiler plate for JMX, but with settings table we
don't... so why force more code on authors?
bq. We will end up with consistency through APIs
Your POC showed me that you only matched a small amount of endpoints, so JMX
would have more than settings table due to these matching rules...
bq. If a property name needs to be renamed, the auto-generated ConfigFields
will immediately show which other calls we should fix;
I have no idea what this means, can you explain?
bq. which will also perform all the necessary input value checks as it does now
I mentioned that the current move is to move that validation into the type
system and not in DD as that has been a maintenance issue for us, so I question
the desire to shift the logic back to DD.
> Allow UPDATE on settings virtual table to change running configurations
> -----------------------------------------------------------------------
>
> Key: CASSANDRA-15254
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15254
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Virtual Tables
> Reporter: Chris Lohfink
> Assignee: Maxim Muzafarov
> Priority: Normal
> Attachments: Configuration Registry Diagram.png
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Allow using UPDATE on the system_views.settings virtual table to update
> configs at runtime for the equivalent of the dispersed JMX
> attributes/operations.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
