cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexander Ivakov (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-14393) Incorrect view updates
Date Thu, 28 Jun 2018 05:06:00 GMT


Alexander Ivakov commented on CASSANDRA-14393:

The above appears to be a design feature implemented in CASSANDRA-11500. See point c) in:

{{view row exists if any of following is true:

a. base row pk has live livenessInfo(timestamp) and base row pk satifies view's filter conditions
if any.
b. or one of base row columns selected in view has live timestamp (via update) and base row
pk satifies view's filter conditions if any. this is handled by existing mechanism of liveness
and tombstone since all info are included in view row
c. or one of base row columns not selected in view has live timestamp (via update) and base
row pk satifies view's filter conditions if any. Those unselected columns' timestamp/ttl/cell-deletion
info are not currently stored on view row.}}

from here:

When a base table row is updated, the corresponding view row has its (primary key) liveness
info updated to that of the update, including ttl and local deletion time. This leads to the
behaviour you see here if the update had a longer ttl than the actual row - the row is marked
with the ttl of the update and remains alive for that length of time (even if the data in
the row is already expired). Note, this only affects the view, the base table row liveness
is not altered (only INSERTs can set the row liveness on tables). Hence, if you query the
table, no results are returned, while querying the view returns a row with empty (expired)
data cells.

Note also that DELETE does not do the above, ie. does not update the row liveness and ttl
of the MV row. 

Perhaps [~jasonstack] can comment?

> Incorrect view updates
> ----------------------
>                 Key: CASSANDRA-14393
>                 URL:
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Materialized Views
>            Reporter: Duarte Nunes
>            Priority: Major
>              Labels: materializedviews
> Consider the following:
> {noformat}
> create table t (p int, c int, v1 int, v2 int, primary key(p, c));
> create materialized view mv as select p, c, v1 from t 
> where p is not null and c is not null primary key (c, p);
> insert into t (p, c, v1, v2) VALUES(1, 1, 1, 1) using ttl 5;
> update t using ttl 1000 set v2 = 1 where p = 1 and c = 1;
> delete v2 from t where p = 1 and c = 1;
> // Wait 5 seconds
> select * from mv;
> c | p | v1
> ---+---+------
> 1 | 1 | null{noformat}
> The view row should be dead after 5 seconds, but it is not.
> This is because the liveness info calculated when deleting v2 is based on the base table
update liveness info, which has the timestamp of the first insert statement. That liveness
info is shadowed by the liveness info created in the update, which has a higher timestamp.

This message was sent by Atlassian JIRA

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message