[ https://issues.apache.org/jira/browse/CASSANDRA-17544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17532774#comment-17532774 ]
Andres de la Peña commented on CASSANDRA-17544: ----------------------------------------------- I'll commit it in a bit, only for {{trunk}}. > 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.x > > Time Spent: 50m > 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: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org