cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-10261) Materialized Views Timestamp issues
Date Wed, 09 Sep 2015 09:55:46 GMT


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|] 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:
>             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