Even if native protocole from 2.0 offers nice paging feature, the tuple
notation is mandatory when paging is handled from client-side.
On Fri, Jul 18, 2014 at 3:15 PM, Mike Heffner wrote:
> Tyler,
>
> Cool, yes I was actually trying to solve that exact problem of paginating
> with LIMIT when
Tyler,
Cool, yes I was actually trying to solve that exact problem of paginating
with LIMIT when it ends up slicing in the middle of a set of composite
columns. (though sounds like automatic ResultSet paging in 2.0.x alleviates
that need).
So to do composite column slicing in 1.2.x the answer is
For this type of query, you really want the tuple notation introduced in
2.0.6 (https://issues.apache.org/jira/browse/CASSANDRA-4851):
SELECT * FROM CF WHERE key='X' AND (column1, column2, column3) > (1, 3, 4)
AND (column1) < (2)
On Thu, Jul 17, 2014 at 6:01 PM, Mike Heffner wrote:
> Michael,
Michael,
So if I switch to:
SELECT * FROM CF WHERE key='X' AND column1=1 AND column2=3 AND column3>4
That doesn't include rows where column1=2, which breaks the original slice
query.
Maybe a better way to put it, I would like:
SELECT * FROM CF WHERE key='X' AND column1>=1 AND column2>=3 AND co
The last term in this query is redundant. Any time column1 = 1, we
may reasonably expect that it is also <= 2 as that's where 1 is found.
If you remove the last term, you elimiate the error and non of the
selection logic.
SELECT * FROM CF WHERE key='X' AND column1=1 AND column2=3 AND
column3>4 AN
