[
https://issues.apache.org/jira/browse/CASSANDRA-12829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15605257#comment-15605257
]
Alex Petrov edited comment on CASSANDRA-12829 at 12/5/16 11:29 AM:
-------------------------------------------------------------------
Patch for the 3.x branches follows.
Problem was occurring only when there was one clustering column. If we're using
empty clustering (taken from restriction) in case of DELETE, we create a
[partition level
deletion|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/cql3/statements/DeleteStatement.java#L59-L63].
However, in this case what we had to do was going through each clustering and
add a tombstone for each row.
In order to correctly handle this case, we now rely on
{{hasClusteringColumnsRestriction}}. This way we know we have to take the
clusterings from restrictions and apply updates/deletes. In case there're no
clustering restrictions (partition-level deletes, updates of static rows,
updating collections on tables with no clusterings etc), we use
{{Clustering.EMPTY}} similar to how it was in this code before
([this|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/MultiCBuilder.java#L262]
part of call).
|[3.0|https://github.com/ifesdjeen/cassandra/tree/12829-3.0]|[dtest|http://cassci.datastax.com/job/ifesdjeen-12829-3.0-dtest/]|[utest|http://cassci.datastax.com/job/ifesdjeen-12829-3.0-testall/]|
|[3.x|https://github.com/ifesdjeen/cassandra/tree/12829-3.x]|[dtest|http://cassci.datastax.com/job/ifesdjeen-12829-3.x-dtest/]|[utest|http://cassci.datastax.com/job/ifesdjeen-12829-3.x-testall/]|
|[trunk|https://github.com/ifesdjeen/cassandra/tree/12829-trunk]|[dtest|http://cassci.datastax.com/job/ifesdjeen-12829-trunk-dtest/]|[utest|http://cassci.datastax.com/job/ifesdjeen-12829-trunk-testall/]|
was (Author: ifesdjeen):
Patch for the 3.x branches follows.
Problem was occurring only when there was one clustering column. If we're using
empty clustering (taken from restriction) in case of DELETE, we create a
[partition level
deletion|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/cql3/statements/DeleteStatement.java#L59-L63].
However, in this case what we had to do was going through each clustering and
add a tombstone for each row.
In order to correctly handle this case, we now rely on
{{hasClusteringColumnsRestriction}}. This way we know we have to take the
clusterings from restrictions and apply updates/deletes. In case there're no
clustering restrictions (partition-level deletes, updates of static rows,
updating collections on tables with no clusterings etc), we use
{{Clustering.EMPTY}} similar to how it was in this code before
([this|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/MultiCBuilder.java#L262]
part of call).
|[3.0|https://github.com/ifesdjeen/cassandra/tree/12829-3.0]|[dtest|http://cassci.datastax.com/job/ifesdjeen-12829-3.0-dtest/]|[utest|http://cassci.datastax.com/job/ifesdjeen-12829-3.0-testall/]|
|[3.X|https://github.com/ifesdjeen/cassandra/tree/12829-3.X]|[dtest|http://cassci.datastax.com/job/ifesdjeen-12829-3.X-dtest/]|[utest|http://cassci.datastax.com/job/ifesdjeen-12829-3.X-testall/]|
|[trunk|https://github.com/ifesdjeen/cassandra/tree/12829-trunk]|[dtest|http://cassci.datastax.com/job/ifesdjeen-12829-trunk-dtest/]|[utest|http://cassci.datastax.com/job/ifesdjeen-12829-trunk-testall/]|
> DELETE query with an empty IN clause can delete more than expected
> ------------------------------------------------------------------
>
> Key: CASSANDRA-12829
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12829
> Project: Cassandra
> Issue Type: Bug
> Components: CQL
> Environment: Arch Linux x64, kernel 4.7.6, Cassandra 3.9 downloaded
> from the website
> Reporter: Jason T. Bradshaw
> Assignee: Alex Petrov
>
> When deleting from a table with a certain structure and using an *in* clause
> with an empty list, the *in* clause with an empty list can be ignored,
> resulting in deleting more than is expected.
> *Setup:*
> {code}
> cqlsh> create table test (a text, b text, id uuid, primary key ((a, b), id));
> cqlsh> insert into test (a, b, id) values ('a', 'b',
> 00000000-0000-0000-0000-000000000000);
> cqlsh> insert into test (a, b, id) values ('b', 'c',
> 00000000-0000-0000-0000-000000000000);
> cqlsh> insert into test (a, b, id) values ('a', 'c',
> 00000000-0000-0000-0000-000000000000);
> cqlsh> select * from test;
> a | b | id
> ---+---+--------------------------------------
> a | c | 00000000-0000-0000-0000-000000000000
> b | c | 00000000-0000-0000-0000-000000000000
> a | b | 00000000-0000-0000-0000-000000000000
> (3 rows)
> {code}
> *Expected:*
> {code}
> cqlsh> delete from test where a = 'a' and b in ('a', 'b', 'c') and id in ();
> cqlsh> select * from test;
> a | b | id
> ---+---+--------------------------------------
> a | c | 00000000-0000-0000-0000-000000000000
> b | c | 00000000-0000-0000-0000-000000000000
> a | b | 00000000-0000-0000-0000-000000000000
> (3 rows)
> {code}
> *Actual:*
> {code}
> cqlsh> delete from test where a = 'a' and b in ('a', 'b', 'c') and id in ();
> cqlsh> select * from test;
> a | b | id
> ---+---+--------------------------------------
> b | c | 00000000-0000-0000-0000-000000000000
> (1 rows)
> {code}
> Instead of deleting nothing, as the final empty *in* clause would imply, it
> instead deletes everything that matches the first two clauses, acting as if
> the following query had been issued instead:
> {code}
> cqlsh> delete from test where a = 'a' and b in ('a', 'b', 'c');
> {code}
> This seems to be related to the presence of a tuple clustering key, as I
> could not reproduce it without one.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
