[
https://issues.apache.org/jira/browse/CASSANDRA-17147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17451933#comment-17451933
]
David Capwell commented on CASSANDRA-17147:
-------------------------------------------
bq. able to use Jackson annotations and have private attributes.
The patch allows plugging SnakeYAML and Jackson for object mapping, but
currently defaults to SnakeYAML; though I did add support for @JsonIgnore, but
other stuff like @JsonProperty are not supported (so can't rename).
bq. I guess that those annotations would also make things easier for the
settings virtual table.
ATM harder! That is another issue we need to solve in Cassandra, settings
vtable makes assumptions which are not valid today (well, if it supported
nested that is), so I am in favor of centralizing the logic of "what is a
property" so YAML AND vtable both use the same code path (it is so much easier
to enhance our logic down the line...); but again, not in this ticket.
bq. I guess we could leave the camel case getters/setters and public snake
case attributes and wait for a better solution
Yeah, I am in favor of that as well. I see this as a bug in our config layer,
so fixing config layer is best IMO. Its present in more than guardrails, so
patching every access is... yeah lets just fix config layer...
bq. We could also use snake casing in the getters/setters
I wouldn't, again I see this as a bug in the config layer, so lets fix config
layer.
> Guardrails prototype
> --------------------
>
> Key: CASSANDRA-17147
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17147
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
> Reporter: Andres de la Peña
> Assignee: Andres de la Peña
> Priority: Normal
> Fix For: 4.x
>
> Time Spent: 14h 50m
> Remaining Estimate: 0h
>
> The purpose of this ticket is creating an initial implementation of the
> guardrails framework, as well as adding a few simple guardrails using this
> framework.
> To keep things easy, this initial implementation would only support
> guardrails that are triggered on the coordinator, and they would be
> dynamically updatable only through JMX.
> Once we have this initial framework ready in a feature branch we can have
> multiple tickets addressing all the things that would have been left out of
> the scope of this ticket, such as:
> * Dynamic updates through virtual tables
> * Being able to notify about guardrails triggered on replicas
> * Using custom exceptions other than {{InvalidRequestException}}.
> * Porting existing limits to use the new guardrails framework
> * Adding new guardrails beyond the initial ones
> The reason for having this simpler prototype is that it will give us a common
> ground to parallelize work on the parts mentioned above.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
