[
https://issues.apache.org/jira/browse/CASSANDRA-12060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15346432#comment-15346432
]
Sylvain Lebresne commented on CASSANDRA-12060:
----------------------------------------------
I didn't said that the inconsistency of this ticket was *due* to
CASSANDRA-9842. I haven't checked closely, but It's almost surely due to the
fact that in 3.0, the underlying paxos read only query the static part, and so
when it gets back an empty result, it really has no way to know the difference
between "the partition just doesn't exist" or "the partition actually exists,
but has nothing for the static part (at least not for the part we have
condition on)".
What I'm saying is that it's due to the same fact than in CASSANDRA-9842:
because ironically 3.0 is able to only query the static part, it doesn't know
when it gets no results anything about the liveness of the partition. I say
ironically because it wasn't a problem in 2.0 due to it being somewhat
imprecise: to query the static part we were simply query the whole partition
(since the storage engine didn't knew about static stuff) with a limit of 1.
Thanks to that though, if we got back no static part, we knew if the partition
was live (meant we did got one row back, it was just not static) or not (we got
nothing back).
And my point is that we should probably try to get back to the 2.x behavior,
because 1) it's more helpful (we get more info when there is not static part)
and 2) that avoid breaking changes between 2.x and 3.x. So in other words,
when we have conditions on a static column, we should probably internally query
both the static part *and* the first live row of the partition. The last part
being slightly inefficient, but necessary to make the distinction between
live/dead partition when there is nothing static. And if we do that, then we
should apply it to both this ticket and the case covered by CASSANDRA-9842.
> Different failure format for failed LWT between 2.x and 3.x
> -----------------------------------------------------------
>
> Key: CASSANDRA-12060
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12060
> Project: Cassandra
> Issue Type: Bug
> Reporter: Alex Petrov
>
> When executing following CQL commands:
> {code}
> CREATE KEYSPACE test WITH replication = {'class': 'NetworkTopologyStrategy',
> 'datacenter1': '1' };
> USE test;
> CREATE TABLE testtable (a int, b int, s1 int static, s2 int static, v int,
> PRIMARY KEY (a, b));
> INSERT INTO testtable (a,b,s1,s2,v) VALUES (2,2,2,null,2);
> DELETE s1 FROM testtable WHERE a = 2 IF s2 IN (10,20,30);
> {code}
> The output is different between {{2.x}} and {{3.x}}:
> 2.x:
> {code}
> cqlsh:test> DELETE s1 FROM testtable WHERE a = 2 IF s2 = 5;
> [applied] | s2
> -----------+------
> False | null
> {code}
> 3.x:
> {code}
> cqlsh:test> DELETE s1 FROM testtable WHERE a = 2 IF s2 = 5;
> [applied]
> -----------
> False
> {code}
> {{2.x}} would although return same result if executed on a partition that
> does not exist at all:
> {code}
> cqlsh:test> DELETE s1 FROM testtable WHERE a = 5 IF s2 = 5;
> [applied]
> -----------
> False
> {code}
> It _might_ be related to static column LWTs, as I could not reproduce same
> behaviour with non-static column LWTs. The most recent change was
> [CASSANDRA-10532], which enabled LWT operations on static columns with
> partition keys only. -Another possible relation is [CASSANDRA-9842], which
> removed distinction between {{null}} column and non-existing row.- (striked
> through since same happens on pre-[CASSANDRA-9842] code.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
