[
https://issues.apache.org/jira/browse/CASSANDRA-20287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Tunnicliffe updated CASSANDRA-20287:
----------------------------------------
Status: Ready to Commit (was: Review In Progress)
> Execution of CreateTriggerStatement should not rely on external state
> ---------------------------------------------------------------------
>
> Key: CASSANDRA-20287
> URL: https://issues.apache.org/jira/browse/CASSANDRA-20287
> Project: Apache Cassandra
> Issue Type: Bug
> Components: Transactional Cluster Metadata
> Reporter: Sam Tunnicliffe
> Assignee: guo Maxwell
> Priority: Normal
> Fix For: 5.x
>
>
> In its current form, {{CreateTriggerStatement}} attempts to load the trigger
> class when the schema transformation is being applied. This is problematic as
> it means the metadata transformation depends on external state and if the
> class cannot be loaded it throws an {{{}InvalidRequestException{}}}. Once the
> log entry with the enclosing {{AlterSchema}} has been committed to the global
> metadata log, it must be applicable by all instances or they will be blocked
> from applying any further metadata transformations.
> The validation of the class loading could be done prior to submission in
> {{{}AlterSchemaStatement::execute{}}}, which would verify the presence of the
> trigger class on the coordinator. Of course, validation passing on the
> coordinator doesn't guarantee that all instances have the necessary classes
> installed on the classpath so we also need to allow the addition of the
> trigger to {{TableMetadata}} even if the trigger class cannot be loaded.
> Equally, the trigger class may become un-loadable at some point after
> creation, which currently causes log replay to fail.
> There are a couple of options for dealing with an unloadable trigger
> implementation, in addition to clearly logging and reporting an appropriate
> metric. When a table being mutated by a client request has a trigger
> configured but not initialised, we could proceed but attach client warnings
> to the response. Alternatively, we could straight up reject writes on the
> table in question. This behaviour could be made configurable, but it may not
> be worth it.
--
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
