[ https://issues.apache.org/jira/browse/CASSANDRA-10261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14729454#comment-14729454 ]
T Jake Luciani commented on CASSANDRA-10261: -------------------------------------------- Pushed fix and test [here|https://github.com/tjake/cassandra/tree/tsbug] I think this same approach would work for CASSANDRA-9664 so long as it gets the existing record. > 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)