[
https://issues.apache.org/jira/browse/CASSANDRA-13409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15994626#comment-15994626
]
ZhaoYang commented on CASSANDRA-13409:
--------------------------------------
{quote}
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;
{quote}
if a regular row tombstone is applied to view, then there will be no shadowable
tombstone applicable for view because no existing data in base.
{quote}
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).
{quote}
same as above, I think regular-tombstone and shadowable-tombtone won't be
co-exist in the same row..
> 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
