[
https://issues.apache.org/jira/browse/CASSANDRA-17544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17530101#comment-17530101
]
Andres de la Peña commented on CASSANDRA-17544:
-----------------------------------------------
[~jmckenzie] not sure this needs to be marked as 4.1, since it's a minor
internal refactor and we can do it at any moment.
The proposed changes look good to me, although we need a rebase to integrate a
couple of enable/disable flags that have been recently added, and then run CI.
> Add EnableFlag to guardrails API
> --------------------------------
>
> Key: CASSANDRA-17544
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17544
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Guardrails
> Reporter: Josh McKenzie
> Assignee: Bernardo Botella Corbi
> Priority: Low
> Fix For: 4.1
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Currently we only have a DisableFlag which, for guardrails where we're
> enabling or disabling a feature, leads to some pretty odd ergonomics in the
> code. For example:
>
> {code:java}
> public static final DisableFlag compactTablesEnabled =
> new DisableFlag("compact_tables",
> state ->
> !CONFIG_PROVIDER.getOrCreate(state).getCompactTablesEnabled(),
> "Creation of new COMPACT STORAGE tables"); {code}
> So far, the usage of these toggle flags appears to be skewed heavily towards
> the inverse, or an EnableFlag that'd look something like this:
> {code:java}
> public static final EnableFlag featureEnabled = new
> EnableFlag("feature_name", state ->
> CONFIG_PROVIDER.getOrCreate(state).getCompactTablesEnabled(), "Text for
> feature"); {code}
> While it's a relatively small change it'll help tidy up some of the
> guardrails framework and make the logic clearer.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
