[jira] [Comment Edited] (CASSANDRA-4851) CQL3: improve support for paginating over composites
[
https://issues.apache.org/jira/browse/CASSANDRA-4851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14255660#comment-14255660
]
Pierre edited comment on CASSANDRA-4851 at 12/22/14 11:55 AM:
--
When I run such query on cqlsh it trigger an error : list index out of range
however it looks like working via session.execute(query)
([cqlsh 5.0.1 | Cassandra 2.1.1 | CQL spec 3.2.0 | Native protocol v3])
was (Author: pierz):
Is this patch included in cassandra 2.1.1 ?
CQL3: improve support for paginating over composites
Key: CASSANDRA-4851
URL: https://issues.apache.org/jira/browse/CASSANDRA-4851
Project: Cassandra
Issue Type: Improvement
Components: API
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
Priority: Minor
Fix For: 2.0.6
Attachments: 4851.txt
Consider the following table:
{noformat}
CREATE TABLE test (
k int,
c1 int,
c2 int,
PRIMARY KEY (k, c1, c2)
)
{noformat}
with the following data:
{noformat}
k | c1 | c2
0 | 0 | 0
0 | 0 | 1
0 | 1 | 0
0 | 1 | 1
{noformat}
Currently, CQL3 allows to slice over either c1 or c2:
{noformat}
SELECT * FROM test WHERE k = 0 AND c1 0 AND c1 2
SELECT * FROM test WHERE k = 0 AND c1 = 1 AND c2 0 AND c2 2
{noformat}
but you cannot express a query that return the 3 last records. Indeed, for
that you would need to do a query like say:
{noformat}
SELECT * FROM test WHERE k = 0 AND ((c1 = 0 AND c2 0) OR c2 0)
{noformat}
but we don't support that.
This can make it hard to paginate over say all records for {{k = 0}} (I'm
saying can because if the value for c2 cannot be very large, an easy
workaround could be to paginate by entire value of c1, which you can do).
For the case where you only paginate to avoid OOMing on a query,
CASSANDRA-4415 will that and is probably the best solution. However, there
may be case where the pagination is say user (as in, the user of your
application) triggered.
I note that one solution would be to add the OR support at least in case like
the one above. That's definitively doable but on the other side, we won't be
able to support full-blown OR, so it may not be very natural that we support
seemingly random combination of OR and not others.
Another solution would be to allow the following syntax:
{noformat}
SELECT * FROM test WHERE k = 0 AND (c1, c2) (0, 0)
{noformat}
which would literally mean that you want records where the values of c1 and
c2 taken as a tuple is lexicographically greater than the tuple (0, 0). This
is less SQL-like (though maybe some SQL store have that, it's a fairly thing
to have imo?), but would be much simpler to implement and probably to use too.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-4851) CQL3: improve support for paginating over composites
[
https://issues.apache.org/jira/browse/CASSANDRA-4851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14255676#comment-14255676
]
Pierre edited comment on CASSANDRA-4851 at 12/22/14 12:01 PM:
--
Hi Aleksey, I edited my posts, indeed it works on 2.1.1 when I use driver, but
I have a bug when I do the exact same query the driver sent in cqlsh
was (Author: pierz):
Hi Aleksey, I edited my posts, indeed it works on 2.1.1 when I use driver, but
I have a bug when i do the exact same query the driver send via cqlsh.
CQL3: improve support for paginating over composites
Key: CASSANDRA-4851
URL: https://issues.apache.org/jira/browse/CASSANDRA-4851
Project: Cassandra
Issue Type: Improvement
Components: API
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
Priority: Minor
Fix For: 2.0.6
Attachments: 4851.txt
Consider the following table:
{noformat}
CREATE TABLE test (
k int,
c1 int,
c2 int,
PRIMARY KEY (k, c1, c2)
)
{noformat}
with the following data:
{noformat}
k | c1 | c2
0 | 0 | 0
0 | 0 | 1
0 | 1 | 0
0 | 1 | 1
{noformat}
Currently, CQL3 allows to slice over either c1 or c2:
{noformat}
SELECT * FROM test WHERE k = 0 AND c1 0 AND c1 2
SELECT * FROM test WHERE k = 0 AND c1 = 1 AND c2 0 AND c2 2
{noformat}
but you cannot express a query that return the 3 last records. Indeed, for
that you would need to do a query like say:
{noformat}
SELECT * FROM test WHERE k = 0 AND ((c1 = 0 AND c2 0) OR c2 0)
{noformat}
but we don't support that.
This can make it hard to paginate over say all records for {{k = 0}} (I'm
saying can because if the value for c2 cannot be very large, an easy
workaround could be to paginate by entire value of c1, which you can do).
For the case where you only paginate to avoid OOMing on a query,
CASSANDRA-4415 will that and is probably the best solution. However, there
may be case where the pagination is say user (as in, the user of your
application) triggered.
I note that one solution would be to add the OR support at least in case like
the one above. That's definitively doable but on the other side, we won't be
able to support full-blown OR, so it may not be very natural that we support
seemingly random combination of OR and not others.
Another solution would be to allow the following syntax:
{noformat}
SELECT * FROM test WHERE k = 0 AND (c1, c2) (0, 0)
{noformat}
which would literally mean that you want records where the values of c1 and
c2 taken as a tuple is lexicographically greater than the tuple (0, 0). This
is less SQL-like (though maybe some SQL store have that, it's a fairly thing
to have imo?), but would be much simpler to implement and probably to use too.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
