Sorry, it seems that I did not provide enough details. IN restrictions are supported on any clustering key as long as ALL the previous clustering keys are restricted by an equality restrictions ( = or IN ). The only way to have a restriction on a clustering column if a previous one has been restricted by a slice restriction (<=, <, > or >=) is by using filtering (since 3.6). Unfortunatly filtering does not support IN restrictions for the moment.
On Tue, Sep 13, 2016 at 8:32 PM, Samba <saas...@gmail.com> wrote: > I am still getting the following error when trying to run a query with > non-equal conditions in where clause > > > Caused by: com.datastax.driver.core.exceptions.InvalidQueryException: > Clustering column "author" cannot be restricted (preceding column "timing" > is restricted by a non-EQ relation) > > > Here is the version details of cassandra: > > show version; > [cqlsh 5.0.1 | Cassandra 3.7 | CQL spec 3.4.2 | Native protocol v4] > > when IN conditions can be run on any (clustering) column, then i suppose > non-equal conditions should also be supported. is my expectation wrong? > > > On Tue, Sep 6, 2016 at 10:08 PM, Benjamin Lerer < > benjamin.le...@datastax.com > > wrote: > > > Since 2.2, IN restrictions are supported on any partition key or > clustering > > colum in SELECT statement. For UPDATE and DELETE statement they are > > supported since 3.0. > > > > Benjamin > > > > On Tue, Sep 6, 2016 at 11:19 AM, Samba <saas...@gmail.com> wrote: > > > > > Hi, > > > > > > I understand, from the documentation, that IN operator is permitted > only > > on > > > the last column in partition and/or on the last column in the > clustering > > > key. > > > > > > I can understand that IN on partition key column being indeterministic > > but > > > i wonder why is IN permitted only on one (last) clustering column. > aren't > > > all the records differing only in clustering columns stay on the same > > node? > > > is it something impossible or is scheduled for future? > > > > > > > > > alternatively, why not distribute the query to all the nodes matching > the > > > IN condition, in parallel, and join the result sets or return as > futures? > > > perhaps this is what map-reduce does -- but why not a distributed > > database > > > execute its queries (functions & aggregates too) on the matching nodes > in > > > its cluster? > > > > > > could you please try explain the rationale behind why it has been done > > so, > > > and if there are any plans to enhancing this behaviour in the near > > future? > > > > > > Thanks & Regards, > > > Samba > > > > > >
