[ 
https://issues.apache.org/jira/browse/CASSANDRA-12952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16098171#comment-16098171
 ] 

ZhaoYang edited comment on CASSANDRA-12952 at 7/24/17 10:06 AM:
----------------------------------------------------------------

LGTM.. using byteman to test atomicity is really brilliant and I learned. now 
apache-c*-dtest is ready, we need to move to new repo. 

failed dtest are irrelevant : 
| 
bootstrap_test.TestBootstrap.consistent_range_movement_false_with_rf1_should_succeed_test
  -> known
| materialized_views_test.py:TestMaterializedViews.view_tombstone_test  ->  the 
tracing format for diggest is wrong:  "Digest mismatch: {} on 127.0.0.1".  I 
will open another ticket for it.


was (Author: jasonstack):
LGTM.. using byteman to test atomicity is really brilliant and I learned. now 
apache-c*-dtest is ready, we need to move to new repo. 

failed dtest are irrelevant : 
>  
> bootstrap_test.TestBootstrap.consistent_range_movement_false_with_rf1_should_succeed_test
>   -> known
> materialized_views_test.py:TestMaterializedViews.view_tombstone_test  ->  the 
> tracing format for diggest is wrong:  "Digest mismatch: {} on 127.0.0.1".  I 
> will open another ticket for it.

> 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]

Reply via email to