[
https://issues.apache.org/jira/browse/CASSANDRA-12952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16074423#comment-16074423
]
Andrés de la Peña commented on CASSANDRA-12952:
-----------------------------------------------
Here are the patches for the affected branches and a couple of dtests:
||[3.0|https://github.com/apache/cassandra/compare/cassandra-3.0...adelapena:12952-3.0]||[3.11|https://github.com/apache/cassandra/compare/cassandra-3.11...adelapena:12952-3.11]||[trunk|https://github.com/apache/cassandra/compare/trunk...adelapena:12952-trunk]||[dtest|https://github.com/riptano/cassandra-dtest/compare/master...adelapena:CASSANDRA-12952]
I ran the patches on our internal CI and the failing tests seem unrelated to
the patches.
The patches modify {{AlterTableStatement}} to send all the updates on the table
and its materialized views in a single schema mutation.
The dtest [rename_column_test
|https://github.com/adelapena/cassandra-dtest/blob/7f079929cb03701da5ed32879c26ee9e38a1d695/materialized_views_test.py#L777]
verifies the regular working of renaming columns in the base table of a
materialized view.
The dtest
[rename_column_atomicity_test|https://github.com/adelapena/cassandra-dtest/blob/7f079929cb03701da5ed32879c26ee9e38a1d695/materialized_views_test.py#L804]
uses a byteman script to kill the node right after the first schema update has
been received, losing the further MV updates. After this, without the patch,
the node is able to start but with a divergence between the schemas of the
table and its view.
> AlterTableStatement propagates base table and affected MV changes
> inconsistently
> --------------------------------------------------------------------------------
>
> Key: CASSANDRA-12952
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12952
> Project: Cassandra
> Issue Type: Bug
> Components: Distributed Metadata, Materialized Views
> Reporter: Aleksey Yeschenko
> Assignee: Andrés de la Peña
> Fix For: 3.0.x, 3.11.x, 4.x
>
>
> In {{AlterTableStatement}}, when renaming columns or changing their types, we
> also keep track of all affected MVs - ones that also need column renames or
> type changes. Then in the end we announce the migration for the table change,
> and afterwards, separately, one for each affected MV.
> This creates a window in which view definitions and base table definition are
> not in sync with each other. If a node fails in between receiving those
> pushes, it's likely to have startup issues.
> The fix is trivial: table change and affected MV change should be pushed as a
> single schema mutation.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
