[
https://issues.apache.org/jira/browse/CASSANDRA-10537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15348246#comment-15348246
]
Alex Petrov edited comment on CASSANDRA-10537 at 6/24/16 2:16 PM:
------------------------------------------------------------------
I've made a simple proof of concept to check how simple it would be to support
this.
It's rather easy, as it requires a small change in grammar, although given the
way the {{ColumnCondition}} is currently implemented, I'd suggest refactoring
it a bit to make it more flexible to support different operations.
* {{ColumnCondition}} supports at least two cases in a single class: for
operators such as {{EQ}}, {{GT}} etc.. and {{IN}}. These cases are mostly
distinct and code might get simpler to read and modify if we had them in
distinct classes
* Other strong distinction that's made is between (for collection) the field
and collection element (for UDT), and "simple" values.
* There's some intersection with {{RowFilter}} and logic is quite similar in
both cases, maybe some code and logic can be reused.
There are enough inner classes that handle all the mentioned distinctions, but
{{ColumnCondition}} itself may benefit from reducing the amount of conditional
logic involved into figuring out distinction, as code paths are rather separate.
was (Author: ifesdjeen):
I've made a simple proof of concept to check how simple it would be to support
this.
It's rather easy, as it requires a small change in grammar, although given the
way the {{ColumnCondition}} is currently implemented, I'd suggest refactoring
it a bit to make it more flexible to support different operations.
* {{ColumnCondition}} supports at least two cases in a single class: for
operators such as {{EQ}}, {{GT}} etc.. and {{IN}}. These cases are mostly
distinct and code might get simpler to read and modify if we had them in
distinct classes
* Other strong distinction that's made is between (for collection) the field
and collection element (for UDT), and "simple" values.
There are enough inner classes that handle all the mentioned distinctions, but
{{ColumnCondition}} itself may benefit from reducing the amount of conditional
logic involved into figuring out distinction, as code paths are rather separate.
> CONTAINS and CONTAINS KEY support for Lightweight Transactions
> --------------------------------------------------------------
>
> Key: CASSANDRA-10537
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10537
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Nimi Wariboko Jr.
> Assignee: Alex Petrov
> Labels: CQL
> Fix For: 3.x
>
>
> Conditional updates currently do not support CONTAINS and CONTAINS KEY
> conditions. Queries such as
> {{UPDATE mytable SET somefield = 4 WHERE pk = 'pkv' IF set_column CONTAINS
> 5;}}
> are not possible.
> Would it also be possible to support the negation of these (ex. testing that
> a value does not exist inside a set)?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
