[
https://issues.apache.org/jira/browse/CASSANDRA-12829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15708858#comment-15708858
]
Alex Petrov commented on CASSANDRA-12829:
-----------------------------------------
Thanks for noticing this. Turns out that my code did same thing, just was much
more complex to parse. Your suggestion is very good.
As regards {{IN}} restriction, it's all quite simple to fix. However, I see a
bit inconsistency. {{IN}} with just one value is simplified to {{EQ}} relation.
{{IN}} with more than 1 value or 0 values will remain {{IN}}. And because
{{IN}} restrictions are not supported with conditional deletions, currently
we'll disallow {{0}} and {{> 1}} values, while {{1}} value will work just as
{{EQ}}.
Do you think such behaviour would be acceptable? Are empty IN restrictions
actually useful or will just cause edge-cases and unclear behaviour?
> 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)
