[
https://issues.apache.org/jira/browse/CASSANDRA-12423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15433801#comment-15433801
]
Tyler Hobbs commented on CASSANDRA-12423:
-----------------------------------------
Regarding the patch, it took me a while to convince myself this was the correct
behavior, so I'll write out some comments for posterity.
In the 2.x world, a range tombstone with a final EOC of 0 results in a
exclusive deletion _except_ for cells that exactly match the tombstone bound.
I made a
[dtest|https://github.com/thobbs/cassandra-dtest/commit/e76250a4471a81a1ece93cc954f42d4a61aa8c2d]
to double check this (which we should commit, I guess). This is why we can't
just use {{EXCL_END_BOUND}} in 3.0 -- in the case where the range tombstone
bound exactly matches a {{ClusteringPrefix}}, we want that to be included in
the deletion.
I think we should change the new enum name from {{INCL_END_BOUND_EOC_0}} to
{{END_BOUND_EOC_0}} for clarity. It's sort of both inclusive and exclusive, so
having either one in the name is confusing, I think. Regarding the code
comment:
bq. This value compares as an inclusive end bound but before any clustering
values. It can be removed once support for thrift and legacy sstables is
removed.
I find the first half of that confusing. Maybe rephrase it as "This value is
inclusive of any exact matches, but does not include any clusterings that it is
merely a prefix of." I believe the second half of the comment is incorrect, as
we'll need to continue treating those range tombstones correctly as long as
they exist. Furthermore, once we've serialized tombstones with that enum
value, we'll always need it for deserialization.
My last concern is around compatibility in a mixed-version cluster. It seems
like there could be problems if you did something like this:
* Have a 2.x cluster with range tombstones with an eoc=0 end bound
* Upgrade to some 3.x that doesn't include this fix
* Then, upgrade some nodes to a 3.y that _does_ include this fix while there
are still legacy sstables
It seems like the 3.y nodes could send results with the new enum value to the
3.x nodes which would then error while deserializing the results. I'm not sure
what to do about that yet. We could require all sstables to be upgraded before
upgrading to 3.10 from 3.x, but that would also force any remaining legacy
tombstones like this to be permanently treated incorrectly, which kind of sucks.
> Cells missing from compact storage table after upgrading from 2.1.9 to 3.7
> --------------------------------------------------------------------------
>
> Key: CASSANDRA-12423
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12423
> Project: Cassandra
> Issue Type: Bug
> Reporter: Tomasz Grabiec
> Assignee: Stefania
> Attachments: 12423.tar.gz
>
>
> Schema:
> {code}
> create table ks1.test ( id int, c1 text, c2 text, v int, primary key (id, c1,
> c2)) with compact storage and compression = {'sstable_compression': ''};
> {code}
> sstable2json before upgrading:
> {code}
> [
> {"key": "1",
> "cells": [["","0",1470761440040513],
> ["a","asd",2470761440040513,"t",1470764842],
> ["asd:","0",1470761451368658],
> ["asd:asd","0",1470761449416613]]}
> ]
> {code}
> Query result with 2.1.9:
> {code}
> cqlsh> select * from ks1.test;
> id | c1 | c2 | v
> ----+-----+------+---
> 1 | | null | 0
> 1 | asd | | 0
> 1 | asd | asd | 0
> (3 rows)
> {code}
> Query result with 3.7:
> {code}
> cqlsh> select * from ks1.test;
> id | 6331 | 6332 | v
> ----+------+------+---
> 1 | | null | 0
> (1 rows)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
