[
https://issues.apache.org/jira/browse/CASSANDRA-10261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14731266#comment-14731266
]
Tyler Hobbs commented on CASSANDRA-10261:
-----------------------------------------
Here's an example of a series of operations along with the corresponding state
of the base and MV rows.
The base table schema: {{CREATE TABLE base (a int, b int, c int, d int, PRIMARY
KEY (a, b))}}
The view schema: {{CREATE MV AS SELECT * FROM base ... PRIMARY KEY (c, a, b)}};
In these examples, {{d=0@1}} means the cell for {{d}} has value 0 and timestamp
1.
{noformat}
INSERT ... (0, 0, 0, 0) @ TS 1
- Base row: pk=(0, 0) row_ts=1, c=0@1, d=0@1
- MV rows:
- pk=(0, 0, 0) row_ts=1, d=0@1
UPDATE ... SET c = 1 @ TS 3
- Base row: pk=(0, 0) row_ts=1, c=1@3, d=0@1
- MV rows:
- pk=(0, 0, 0) view_tombstone@3
- pk=(1, 0, 0) row_ts=3, d=0@1
{noformat}
This update created a "view tombstone" in the view with timestamp 3. Since
this was higher than the row timestamp for the view's row, it was considered
deleted.
{noformat}
UPDATE ... SET c = 0 @ TS 4
- Base row: pk=(0, 0) row_timestamp=1, c=1@4, d=0@1
- MV rows:
- pk=(0, 0, 0) view_tombstone@3, row_ts=4, d=0@1
- pk=(1, 0, 0) view_tombstone@4,
{noformat}
The view row was reinserted with c=0. Since the new view row has a timestamp
of 4, the "view tombstone" with timestamp 3 does not shadow it, including the
protected cell {{d}} with a timestamp of 1.
{noformat}
UPDATE ... SET d = 1 @ TS 2
- Base row: pk=(0, 0) row_ts=1, c=1@4, d=1@2
- MV rows:
- pk=(0, 0, 0) view_tombstone@3, row_ts=4, d=1@2
- pk=(1, 0, 0) view_tombstone@4
UPDATE ... SET d = 2 @ TS 3
- Base row: pk=(0, 0) row_ts=1, c=1@4, d=2@3
- MV rows:
- pk=(0, 0, 0) view_tombstone@3, row_ts=4, d=2@3
- pk=(1, 0, 0) view_tombstone@4
{noformat}
The {{d}} cell can be updated normally without adjustments to its timestamp.
{noformat}
DELETE ... WHERE a = 0 AND b = 0 @ TS 5
- Base row: pk=(0, 0) tombstone@5
- MV rows:
- pk=(0, 0, 0) tombstone@5
- pk=(1, 0, 0) view_tombstone@4
{noformat}
Deletions on the base table result in normal tombstones being inserted to the
view.
> 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)
