[
https://issues.apache.org/jira/browse/CASSANDRA-9928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14723695#comment-14723695
]
Joel Knighton commented on CASSANDRA-9928:
------------------------------------------
Guaranteeing a quorum of nodes will see the updates does not solve the problem
because supporting multiple non-primary key columns in the materialized view
primary key introduces a sensitivity to the ordering of updates to these
non-primary key columns.
I think this is the simplest version of Benedict's example. Envision a cluster
with a table with primary key P and columns A and B. Presently, all replicas
contain an entry for P=1, A=1, B=1.
Two concurrent updates are occurring - one setting A=2, and one setting B=2.
One replica receives the update B=2, removes the MV entry for P=1, A=1, B=1,
creates an MV entry for P=1, A=1, B=2, and then crashes with data loss. The
remainder of the base replicas receive the update A=2; remove the MV entry for
P=1, A=1, B=1; create an MV entry for P=1, A=2, B=1; receive the update B=2;
remove the MV entry for P=1, A=2, B=1; and create an MV entry for P=1, A=2, B=2.
Upon repairing the data lost base replica from the remaining base replicas, a
delete for the entry P=1, A=1, B=2 in the paired replica will never be created.
> Add Support for multiple non-primary key columns in Materialized View primary
> keys
> ----------------------------------------------------------------------------------
>
> Key: CASSANDRA-9928
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9928
> Project: Cassandra
> Issue Type: Improvement
> Reporter: T Jake Luciani
> Labels: materializedviews
> Fix For: 3.x
>
>
> Currently we don't allow > 1 non primary key from the base table in a MV
> primary key. We should remove this restriction assuming we continue
> filtering out nulls. With allowing nulls in the MV columns there are a lot
> of multiplicative implications we need to think through.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
