[jira] [Updated] (CASSANDRA-12952) AlterTableStatement propagates base table and affected MV changes inconsistently
[
https://issues.apache.org/jira/browse/CASSANDRA-12952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh McKenzie updated CASSANDRA-12952:
--
Bug Category: Parent values: Availability(12983)Level 1 values:
Unavailable(12994)
> 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: Feature/Materialized Views, Legacy/Distributed Metadata
>Reporter: Aleksey Yeschenko
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 3.0.15, 3.11.1, 4.0
>
>
> 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
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-12952) AlterTableStatement propagates base table and affected MV changes inconsistently
[
https://issues.apache.org/jira/browse/CASSANDRA-12952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Shuler updated CASSANDRA-12952:
---
Fix Version/s: (was: 3.11.x)
(was: 4.x)
(was: 3.0.x)
3.0.15
3.11.1
4.0
> 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: Feature/Materialized Views, Legacy/Distributed Metadata
>Reporter: Aleksey Yeschenko
>Assignee: Andrés de la Peña
>Priority: Normal
> Fix For: 3.0.15, 3.11.1, 4.0
>
>
> 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
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-12952) AlterTableStatement propagates base table and affected MV changes inconsistently
[
https://issues.apache.org/jira/browse/CASSANDRA-12952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrés de la Peña updated CASSANDRA-12952:
--
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
> 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: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-12952) AlterTableStatement propagates base table and affected MV changes inconsistently
[
https://issues.apache.org/jira/browse/CASSANDRA-12952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrés de la Peña updated CASSANDRA-12952:
--
Status: Ready to Commit (was: Patch Available)
> 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: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-12952) AlterTableStatement propagates base table and affected MV changes inconsistently
[
https://issues.apache.org/jira/browse/CASSANDRA-12952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergio Bossa updated CASSANDRA-12952:
-
Reviewer: ZhaoYang
> 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: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-12952) AlterTableStatement propagates base table and affected MV changes inconsistently
[
https://issues.apache.org/jira/browse/CASSANDRA-12952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrés de la Peña updated CASSANDRA-12952:
--
Status: Patch Available (was: In Progress)
> 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: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-12952) AlterTableStatement propagates base table and affected MV changes inconsistently
[
https://issues.apache.org/jira/browse/CASSANDRA-12952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrés de la Peña updated CASSANDRA-12952:
--
Fix Version/s: 4.x
> 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: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-12952) AlterTableStatement propagates base table and affected MV changes inconsistently
[
https://issues.apache.org/jira/browse/CASSANDRA-12952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeremy Hanna updated CASSANDRA-12952:
-
Component/s: Materialized Views
> 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
> Fix For: 3.0.x, 3.11.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: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-12952) AlterTableStatement propagates base table and affected MV changes inconsistently
[
https://issues.apache.org/jira/browse/CASSANDRA-12952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Yeschenko updated CASSANDRA-12952:
--
Component/s: Distributed Metadata
> 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
>Reporter: Aleksey Yeschenko
> Fix For: 3.0.x, 3.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.3.4#6332)
