[
https://issues.apache.org/jira/browse/CASSANDRA-19593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17848171#comment-17848171
]
Stefan Miklosovic edited comment on CASSANDRA-19593 at 5/21/24 11:45 AM:
-------------------------------------------------------------------------
Progress:
I finished all transformations (Flags, Values, Thresholds, Customs) (Custom is
a custom guardrail as per CEP-24). I have also tested ser/de of these
transformations, there are tests for vtables and diffing of transformations as
well.
I have also started to validate the input in vtables before it is committed to
TCM. That means that no invalid configuration (e.g. warn threshold bigger than
fail threshold) will be committed when CQL statement against such vtables is
executed. Validations are done per each logical guardrail category if
applicable.
It is worth to say that from the implementation perspective, Values (related to
values guardrail) are rather special when it comes to CQL.
If we want to have this table
{code:java}
VIRTUAL TABLE system_guardrails.values (
name text PRIMARY KEY,
disallowed frozen<set<text>>,
ignored frozen<set<text>>,
warned frozen<set<text>>
) {code}
when we do this query:
{code:java}
update system_guardrails.values set warned = {'QUORUM'}, disallowed =
{'EACH_QUORUM'} WHERE name = 'read_consistency_levels'; {code}
the way how it works until now is that each value for respective column will
come to
AbstractMutableVirtualTable#applyColumnUpdate. But, think about that, if we
have two columns modified, as in the above example, that would translate to two
separate commits into TCM, just because mutable vtable iterates over such
columns.
I do not think this is desirable, there should be one commit per query,
basically. So the transformation might contain more than one column.
In order to do that, I had to override "apply" method in
AbstractMutableVirtualTable and I had to remove "final" modifier. This was
already discussed with [~blerer] that it might be possible to remove that in
order to accommodate this kind of situations.
Also, I am making sure that I am not committing something which has not
changed. E.g. when I execute above query twice, it will be actually committed
just once, because for the second time, when diffing it, there is no
difference, hence no commit is necessary. This was quite tricky to get right,
especially for values, because I wanted to model the situation when we are
removing the value by setting it to null, like this:
{code:java}
update system_guardrails.values set warned = null, disallowed = {} WHERE name =
'read_consistency_levels'; {code}
"null" and "empty" are two different operations in terms of mutable vtable. If
it is set to null, it is looked at as if we are going to delete but if it is an
empty set, it is a regular update. This was tricky to get right too but I think
I am there.
was (Author: smiklosovic):
Progress:
I finished all transformations (Flags, Values, Thresholds, Customs) (Custom is
a custom guardrail as per CEP-24). I have also tested ser/de of these
transformations, there are tests for vtables and diffing of transformations as
well.
I have also started to validate the input in vtables before it is committed to
TCM. That means that no invalid configuration (e.g. warn threshold bigger than
fail threshold) will be committed when CQL statement against such vtables is
executed. Validations are done per each logical guardrail category if
applicable.
> Transactional Guardrails
> ------------------------
>
> Key: CASSANDRA-19593
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19593
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails, Transactional Cluster Metadata
> Reporter: Stefan Miklosovic
> Assignee: Stefan Miklosovic
> Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I think it is time to start to think about this more seriously. TCM is
> getting into pretty nice shape and we might start to investigate how to do
> this.
--
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
