cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benjamin Lerer <benjamin.le...@datastax.com>
Subject Re: restrictions on IN operator
Date Wed, 14 Sep 2016 12:17:47 GMT
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 <saasira@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.lerer@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 <saasira@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
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message