[
https://issues.apache.org/jira/browse/CASSANDRA-10261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14731222#comment-14731222
]
Tyler Hobbs commented on CASSANDRA-10261:
-----------------------------------------
Thinking about this more, a bit of a hybrid of the two approaches I mentioned
may work. Essentially, we use two kinds of tombstones in MVs:
* View tombstones. These have a special deletion behavior. If the row
timestamp is higher than the tombstone's timestamp, all of the cells in the row
are safe, regardless of their own timestamp. These tombstones would be used
whenever we need an MV deletion as a result of a non-deletion change in the
base table. To use the original example, when {{c}} is changed from 0 to 1 in
the base table, we would insert a "view tombstone" into the view with {{c}}'s
timestamp.
* Normal tombstones. These function just like the existing tombstones, and
shadow any cell with a lower timestamp, regardless of the row's timestamp.
These are used whenever there is a deletion on the base table.
I'm working on some examples of how this would behave.
As far as the implementation goes, it may be simpler to model this as one kind
of tombstone with two separate timestamps, but I'm not sure yet.
> 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)
