[
https://issues.apache.org/jira/browse/CASSANDRA-7855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14117519#comment-14117519
]
Todd Nine commented on CASSANDRA-7855:
--------------------------------------
I would argue that the syntax should always have the following format.
{code}
SELECT * FROM foo WHERE (k1, k2) IN ( (0, 1) , (1, 2) )
{code}
Simply because in the use case provided in my ticket, you know all possible
combinations of fields to construct partition keys. By grouping them together
within the parenthesis, it is clear to both the user and the grammar that all
terms within the parens comprise a partition key. By reading the above it is
clear that (0, 1) is a partition key, as is (1, 2)
> Genralize use of IN for compound partition keys
> -----------------------------------------------
>
> Key: CASSANDRA-7855
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7855
> Project: Cassandra
> Issue Type: Bug
> Reporter: Sylvain Lebresne
> Priority: Minor
> Labels: cql
> Fix For: 2.0.11
>
>
> When you have a compount partition key, we currently only support to have a
> {{IN}} on the last column of that partition key. So given:
> {noformat}
> CREATE TABLE foo (
> k1 int,
> k2 int,
> v int,
> PRIMARY KEY ((k1, k2))
> )
> {noformat}
> we allow
> {noformat}
> SELECT * FROM foo WHERE k1 = 0 AND k2 IN (1, 2)
> {noformat}
> but not
> {noformat}
> SELECT * FROM foo WHERE k1 IN (0, 1) AND k2 IN (1, 2)
> {noformat}
> There is no particular reason for us not supporting the later (to the best of
> my knowledge) since it's reasonably straighforward, so we should fix it.
> I'll note that using {{IN}} on a partition key is not necessarily a better
> idea than parallelizing queries server client side so this syntax, when
> introduced, should probably be used sparingly, but given we do support IN on
> partition keys, I see no reason not to extend it to compound PK properly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
