cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tyler Hobbs (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-10261) Materialized Views Timestamp issues
Date Tue, 08 Sep 2015 22:35:46 GMT


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:
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: T Jake Luciani
>            Assignee: T Jake Luciani
>             Fix For: 3.0.0 rc1
> As [~thobbs] [mentioned|]
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

View raw message