[
https://issues.apache.org/jira/browse/CASSANDRA-10261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14729810#comment-14729810
]
Joel Knighton edited comment on CASSANDRA-10261 at 9/3/15 9:58 PM:
-------------------------------------------------------------------
This approach does not appear to work.
In particular, if multiple updates are made to a cell with distinct timestamps
less than the primary key timestamp, these updates will get promoted to the
same primary key timestamp, which will cause different merging behavior on the
view than the base.
EDIT: For example, consider the following case:
1. On the base, the columns of the MV's PK are at TS=4.
2. A write for normal column D=2 is made at TS=2.
3. On the view, this write is promoted to TS=4 to avoid tombstone problems.
4. A write for normal column D=1 is made at TS=3.
5. On the view, this write is promoted to TS=4 to avoid tombstone problems.
On the base, the second write wins. On the view, since timestamps are equal,
the first write wins by lexicographic ordering.
A unit test showing such a failure is available on my repo branch
[tsbug|https://github.com/jkni/cassandra/tree/tsbug].
was (Author: jkni):
This approach does not appear to work.
In particular, if multiple updates are made to a cell with distinct timestamps
less than the primary key timestamp, these updates will get promoted to the
same primary key timestamp, which will cause different merging behavior on the
view than the base.
> 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)
