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 >
