[
https://issues.apache.org/jira/browse/CASSANDRA-12952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16102994#comment-16102994
]
Andrés de la Peña commented on CASSANDRA-12952:
-----------------------------------------------
Thanks for the review. Here are the rebased versions of the patch and the
dtests for apache/cassandra-dtest:
||[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/apache/cassandra-dtest/compare/master...adelapena:12952]
> 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]
