Duarte Nunes created CASSANDRA-13409:
----------------------------------------
Summary: Materialized Views: View cells is resurrected
Key: CASSANDRA-13409
URL: https://issues.apache.org/jira/browse/CASSANDRA-13409
Project: Cassandra
Issue Type: Bug
Reporter: Duarte Nunes
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)
