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 > > >
