[
https://issues.apache.org/jira/browse/CASSANDRA-10226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14739057#comment-14739057
]
Tyler Hobbs commented on CASSANDRA-10226:
-----------------------------------------
bq. The problem is if you need to add another weak tombstone because c is set
to null again you will add another weak tombstone at ts=0 (since it's the min
timestamp of the PK)
Ah, good catch.
bq. If you put the list in the Row.Deletion as well then you can apply the
rule to exclude based on each component (regular tombstone if any tombstone ts
is > liveness offset) vs (shadowable if all ts are > liveness offsets)
Okay, so basically both the LivenessInfo and the Row.Deletion hold a list of
timestamps in views. To see if a tombstone deletes a row, we pairwise check
each LivenessInfo timestamp against the corresponding Row.Deletion timestamp.
If the Row.Deletion timestamp is higher in any pair, the row is considered
deleted. For shadowable tombstones, we stop here. For regular tombstones, if
the row isn't considered deleted, we proceed to check each cell in the row
against the max timestamp in the Row.Deletion. If the max Row.Deletion
timestamp is higher, the cell is considered deleted.
> 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)
