[
https://issues.apache.org/jira/browse/CASSANDRA-10261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14735754#comment-14735754
]
Tyler Hobbs commented on CASSANDRA-10261:
-----------------------------------------
Some more review feedback:
* I believe you need to update {{DeletionTime.equals()}}, {{hashCode()}},
{{compareTo()}}. If any of those should not account for the new flag, add a
comment explaining why. It would also be nice to add the flag to
{{toString()}}. You already mentioned digests, but I believe we do want to
include the new flag in the digest to cover the case where one replica has a
normal tombstone and another has a weak tombstone with the same timestamp (see
the next point). Make sure the digests changes are also backwards-compatible
(see CASSANDRA-9554).
* {{DeletionTime.supersedes()}} should take the new flag into account. We want
normal tombstones to supersede weak ones because they can delete cells that
weak tombstones cannot. Some tests around this would be good.
* In {{SinglePartitionNamesCommand}}, why should we ignore weak tombstones? If
the sstable doesn't have any newer data, it will still be considered deleted.
* In {{Rows}}, we should be checking that {{mergedInfo.timestamp() >
deletion.markedForDeleteAt()}}, not {{>=}}. Better yet, use
{{deletion.deletes(mergedInfo.timestamp())}}. The changes in {{Row}} have the
same issue.
> Materialized Views Timestamp issues
> -----------------------------------
>
> Key: CASSANDRA-10261
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10261
> Project: Cassandra
> Issue Type: Bug
> Reporter: T Jake Luciani
> Assignee: T Jake Luciani
> Fix For: 3.0.0 rc1
>
>
> As [~thobbs]
> [mentioned|https://issues.apache.org/jira/browse/CASSANDRA-9664?focusedCommentId=14724150&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14724150]
> in CASSANDRA-9664 there are issues dealing with updates to individual cells
> which can mask data from the base table in the view when trying to filter
> data correctly in the view.
> Unfortunately, this same issue exists for all MV tables with regular columns.
> In the earlier versions of MV we did have a fix for this which I now can see
> is ineffective for all situations.
> I've pushed some unit tests to show the issue (similar to tylers) and a fix.
> The idea is we keep the base table's timestamps per cell as it so we can
> *always* tell (per replica) which version of the record is the latest. Since
> the base table *always* writes the entire record to the view (part of our
> earlier partial fix) we can ensure the view record contains *at least* views
> primary key timestamp.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
