cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeff Jirsa (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-13409) Materialized Views: View cells are resurrected
Date Mon, 17 Jul 2017 22:01:00 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-13409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16090652#comment-16090652
] 

Jeff Jirsa commented on CASSANDRA-13409:
----------------------------------------

[~slebresne] - since  CASSANDRA-11475 seems to have caused this regression, and since you
probably understand current state of the engine better than anyone else, any chance you have
feedback here on the right way to solve this once and for all? 



> Materialized Views: View cells are resurrected
> ----------------------------------------------
>
>                 Key: CASSANDRA-13409
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-13409
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Local Write-Read Paths, Materialized Views
>            Reporter: Duarte Nunes
>            Assignee: ZhaoYang
>
> Consider the following commands, ran against trunk@0f054fee5c:
> {code:xml}
> echo "create keyspace ks WITH replication = {'class': 'SimpleStrategy', 'replication_factor':
1};" | bin/cqlsh
> echo "create table ks.base (p int primary key, v1 int, v2 int) with gc_grace_seconds
= 1;" | bin/cqlsh
> echo "create materialized view ks.my_view as select * from ks.base where p is not null
and v1 is not null primary key (v1, p);" | bin/cqlsh
> echo "insert into ks.base (p, v1, v2) values (3, 1, 3) using timestamp 1;" | bin/cqlsh
> bin/nodetool flush ks my_view base
> echo "delete from ks.base using timestamp 2 where p = 3;" | bin/cqlsh
> bin/nodetool flush ks my_view base
> echo "insert into ks.base (p, v1) values (3, 1) using timestamp 3;" | bin/cqlsh
> bin/nodetool flush ks my_view base
> echo "select * from ks.my_view;" | bin/cqlsh
>  v1 | p | v2
> ----+---+----
>   1 | 3 |  3
> (1 rows)
> echo "select * from ks.base;" | bin/cqlsh
>  p | v1 | v2
> ---+----+------
>  3 |  1 | null
> (1 rows)
> {code}
> As you can see, this incorrectly brings back cell v2=3. 
> There is one definitive problem and a potential one:
> * Merging rows must be commutative. If a shadowable tombstone is applied after a row
tombstone, it will replace that tombstone; if a row marker shadows the shadowable tombstone
before the row containing the original data is applied, then any dead cells in said data will
be resurrected;
> * Shadowable tombstones shouldn't compact away previous row tombstones or even deleted
cells; if the relevant tombstones have been GCed from the base table, then a base table update
won't carry them anymore (alongside a newer row marker).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org


Mime
View raw message