[jira] [Updated] (CASSANDRA-20287) Execution of CreateTriggerStatement and CreateIndexStatement should not rely on external state

["guo Maxwell (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CASSANDRA-20287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

guo Maxwell updated CASSANDRA-20287:
------------------------------------
    Summary: Execution of CreateTriggerStatement and CreateIndexStatement should not rely on external state  (was: Execution of CreateTriggerStatement should not rely on external state)

> Execution of CreateTriggerStatement and CreateIndexStatement 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-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org