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
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 m...@librato.com wrote:
Tyler,
Cool, yes I was actually trying to solve that exact problem of paginating
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
column34 AND
Michael,
So if I switch to:
SELECT * FROM CF WHERE key='X' AND column1=1 AND column2=3 AND column34
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
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 m...@librato.com
