[
https://issues.apache.org/jira/browse/CASSANDRA-10226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14740391#comment-14740391
]
Sylvain Lebresne commented on CASSANDRA-10226:
----------------------------------------------
I haven't followed everything here yet, but what is discussed here doesn't
sound like a trivial change, and it sounds like it adds non negligible
complexity to {{Row}} which is very much our core abstraction. It follows that
sneaking such change very late in rc1, which little time to consider
alternative, make me *very* nervous (this is not a judgement of the merit of
the suggested solution btw). So I'd like some clarification: is the problem
discussed here only a problem for having multiple non-PK cols? If it is (only a
problem for this ticket), then I would be strongly in favor of postponing that
ticket to post-3.0. If it is however a problem for MVs as they are currently
implemented, then could 1) provide an example that shows the problem without
multiple non-pk cols in the MV clustering and 2) can you open a separate ticket
focused on that problem.
> 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)
