[
https://issues.apache.org/jira/browse/CASSANDRA-9928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14651989#comment-14651989
]
Carl Yeksigian commented on CASSANDRA-9928:
-------------------------------------------
[~benedict] brought up some potential issues in [a
comment|https://issues.apache.org/jira/browse/CASSANDRA-6477#MultipleColumns]
on CASSANDRA-6477:
{quote}
As far as multiple columns are concerned: I think we may need to go back to the
drawing board there. It's actually really easy to demonstrate the cluster
getting into broken states. Say you have three columns, A B C, and you send
three competing updates a b c to their respective columns; previously all held
the value _. If they arrive in different orders on each base-replica we can end
up with 6 different MV states around the cluster. If any base replica dies, you
don't know which of those 6 intermediate states were taken (and probably
replicated) by its MV replicas. This problem grows exponentially as you add
"competing" updates (which, given split brain, can compete over arbitrarily
long intervals).
This is where my concern about a "single (base) node" dependency comes in, but
after consideration it's clear that with a single column this problem is
avoided because it's never ambiguous what the old state was. If you encounter a
mutation that is shadowed by your current data, you can always issue a delete
for the correct prior state. With multiple columns that is no longer possible.
I'm pretty sure the presence of multiple columns introduces other issues with
each of the other moving parts.
{quote}
When we implement this feature, we should make sure to also add jepsen tests
for the possible problems.
> 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.0 beta 1
>
>
> 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)
