[
https://issues.apache.org/jira/browse/CASSANDRA-13409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15990944#comment-15990944
]
ZhaoYang edited comment on CASSANDRA-13409 at 5/3/17 6:56 AM:
--------------------------------------------------------------
ok..[10261|https://issues.apache.org/jira/browse/CASSANDRA-10261] actually
fixed this issue, but since no test case for this scenario is provied,
somewhere regression happened..
View tombstones generated by base row deletion should be regular tombstone
instead of shadowable tombstone, but unfortunately in this case, they are
created as shadowable...
The regression maybe happened here
[11475|https://issues.apache.org/jira/browse/CASSANDRA-11475]
will try to fix it this week..
was (Author: jasonstack):
ok..[10261|https://issues.apache.org/jira/browse/CASSANDRA-10261] actually
fixed this issue, but since no test case for this scenario is provied,
somewhere regression happened..
View tombstones generated by base deletion should be regular tombstone instead
of shadowable tombstone, but unfortunately in this case, they are created as
shadowable...
The regression maybe happened here
[11475|https://issues.apache.org/jira/browse/CASSANDRA-11475]
will try to fix it this week..
> 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.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
