[
https://issues.apache.org/jira/browse/CASSANDRA-19532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17835549#comment-17835549
]
Stefan Miklosovic edited comment on CASSANDRA-19532 at 4/9/24 11:25 PM:
------------------------------------------------------------------------
It depends how granular we want this to have. This boils down to two
guardrails. The first one deals with creation, the second one deals with
incorporating trigger on actual query.
When we take the first one into consideration, the guardrail type would be of
EnableFlag and it again boils to whether we want to emit a warning or not but
still enable triggers to be created or we just flat out error out on an attempt
to create a trigger. If we want to warn but still want to create a trigger we
need to base this guardrail on the second constructor of EnableFlag taking
"warned" and "enabled" predicates. Then in cassandra.yaml it would look like
this:
triggers_create_enabled: true/false
triggers_create_warned: true/false
I think that the first one should be "true" by default. It is questionable what
you want to have the second one like. If it is "true", then it will by default
warn upon trigger creation. If this is false, it would not. If the first one is
"true" then creation of a trigger is possible, if it is false, it will fail the
query.
The second guardrail deals with including the trigger when a query is executed.
I think that should happen as the very first thing in
TriggerExecutor.execute(mutations) method. The guardrail would consist of a
simple EnableFlag, the first constructor, taking in just one predicate, if it
is enabled, trigger would be executed, if it is disabled, it wont, but the
underlying query itself will not be affected.
I think we need to have two guardrails, because guarding the creation of a
trigger via CreateTriggerStatement is something else from incorporating the
execution of it after it is created. For example, an admin might disable
trigger creation, but she wants to enable existing triggers to be processed. So
the first guardrail would be disabled, but the second one would be enabled.
was (Author: smiklosovic):
It depends how granular we want this to have. This boils down to two
guardrails. The first one deals with creation, the second one deals with
incorporating trigger on actual query.
When we take the first one into consideration, the guardrail type would be of
EnableFlag and it again boils to whether we want to emit a warning or not but
still enable triggers to be created or we just flat out error out on an attempt
to create a trigger. If we want to warn but still want to create a trigger we
need to base this guardrail on the second constructor of EnableFlag taking
"warned" and "enabled" predicates. Then in cassandra.yaml it would look like
this:
triggers_create_enabled: true/false
triggers_warned: true/false
I think that the first one should be "true" by default. It is questionable what
you want to have the second one like. If it is "true", then it will by default
warn upon trigger creation. If this is false, it would not. If the first one is
"true" then creation of a trigger is possible, if it is false, it will fail the
query.
The second guardrail deals with including the trigger when a query is executed.
I think that should happen as the very first thing in
TriggerExecutor.execute(mutations) method. The guardrail would consist of a
simple EnableFlag, the first constructor, taking in just one predicate, if it
is enabled, trigger would be executed, if it is disabled, it wont, but the
underlying query itself will not be affected.
I think we need to have two guardrails, because guarding the creation of a
trigger via CreateTriggerStatement is something else from incorporating the
execution of it after it is created. For example, an admin might disable
trigger creation, but she wants to enable existing triggers to be processed. So
the first guardrail would be disabled, but the second one would be enabled.
> Allow operators to disable the execution of triggers
> ----------------------------------------------------
>
> Key: CASSANDRA-19532
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19532
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Other
> Reporter: Abe Ratnofsky
> Assignee: Abe Ratnofsky
> Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently, triggers are discouraged but there's no explicit way to disable
> them. Similar configuration already exists to disable other features, such as
> "conf.materialized_views_enabled". There should be a means for operators to
> gracefully disable the creation and execution of triggers.
>
> I have a patch ready for this, getting a first review now and will push it
> shortly.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
