[
https://issues.apache.org/jira/browse/CASSANDRA-14393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16525917#comment-16525917
]
Alexander Ivakov edited comment on CASSANDRA-14393 at 6/28/18 5:52 AM:
-----------------------------------------------------------------------
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:
https://issues.apache.org/jira/browse/CASSANDRA-11500?focusedCommentId=16082241&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16082241
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 (view) 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?
was (Author: alex.ivakov):
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:
https://issues.apache.org/jira/browse/CASSANDRA-11500?focusedCommentId=16082241&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16082241
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: https://issues.apache.org/jira/browse/CASSANDRA-14393
> 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
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
