[
https://issues.apache.org/jira/browse/CASSANDRA-20287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18020255#comment-18020255
]
guo Maxwell commented on CASSANDRA-20287:
-----------------------------------------
results seem to be ok :
Tests / dtest-latest jdk17 34/64 /
dtest-latest.client_request_metrics_test.TestClientRequestMetrics.test_client_request_metrics
Tests / dtest-latest jdk17 4/64 /
dtest-latest.cqlsh_tests.test_cqlsh_copy.TestCqlshCopy.test_bulk_round_trip_blogposts_with_max_connections
Tests / dtest jdk17 34/64 /
dtest.client_request_metrics_test.TestClientRequestMetrics.test_client_request_metrics
Tests / test-latest jdk17 10/16 /
org.apache.cassandra.io.sstable.indexsummary.IndexSummaryTest.testLargeIndexSummary-cassandra.testtag_IS_UNDEFINED
Tests / test jdk17 10/16 /
org.apache.cassandra.io.sstable.indexsummary.IndexSummaryTest.testLargeIndexSummary-cassandra.testtag_IS_UNDEFINED
> 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: [email protected]
For additional commands, e-mail: [email protected]
