[ https://issues.apache.org/jira/browse/CASSANDRA-10226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14723636#comment-14723636 ]
T Jake Luciani commented on CASSANDRA-10226: -------------------------------------------- Also, how is this any different than a secondary index? > Support multiple non-PK cols in MV clustering key when partition key is shared > ------------------------------------------------------------------------------ > > Key: CASSANDRA-10226 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10226 > Project: Cassandra > Issue Type: Improvement > Components: Core > Reporter: Tyler Hobbs > Assignee: Tyler Hobbs > Labels: materializedviews > Fix For: 3.0.0 rc1 > > > This issue is similar to CASSANDRA-9928, but with one key limitation: the MV > partition key must match the base table's partition key. This limitation > results in the base replica always pairing with itself as the MV replica. > Because of this pairing, if the base replica is lost, any MV rows that would > otherwise be ambiguous are also lost. This allows us to avoid the problem > described in 9928 of not knowing which MV row to delete. > Although this limitation has the potential to be a bit confusing for users, I > believe this improvement is still worthwhile because: > * The base table's partition key will often be a good choice for the MV > partition key as well. I expect it to be common for users to partition data > the same way, but use a different clustering order to optimize for (or allow > for) different queries. > * It may take a long time to solve the problems presented in 9928 in general > (if we can solve them at all). On the other hand, this is straightforward > and is a significant improvement to the usability of MVs. > I have a minimal prototype of this that works well, so I should be able to > upload a patch with thorough tests within the next few days. -- This message was sent by Atlassian JIRA (v6.3.4#6332)