[
https://issues.apache.org/jira/browse/CASSANDRA-10261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14736570#comment-14736570
]
Sylvain Lebresne commented on CASSANDRA-10261:
----------------------------------------------
And so it doesn't sound like I'm criticizing without offering anything, I've
pushed a branch [here|https://github.com/pcmanus/cassandra/commits/10261] with
the alternative I have in mind. Instead of adding a flag directly to
{{DeletionTime}} (since I don't think it's a good idea for reasons explain in
my previous comment), it adds a new {{Row.Deletion}} class that just group a
{{DeletionTime}} and new {{isWeak}} flag. This makes sure we don't mess with
anything else than row deletions (and a bonus of having a new class is that
type checking make it more sure that we don't forget to handle the new flag
somewhere we should). The serialization also use the first idea of my earlier
comment: it uses a row flag extension which is only there if a weak deletion is
used or the row is static (one existing flag had to move to the extension, and
moving the {{IS_STATIC}} felt the best choice because not every table has
statics and even when they have, there is at most one static row per partition,
and so the slight overhead is somewhat contained). Anyway, the branch steals
the unit test from Jake's branch and said test passes as expected.
> 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)
