[ https://issues.apache.org/jira/browse/CASSANDRA-4851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13902562#comment-13902562 ]
Aleksey Yeschenko commented on CASSANDRA-4851: ---------------------------------------------- LGTM, +1 Tiny nits: - CT.Builder.add() had a (now) unused line {code}int current = components.size();{code} - SelectStatement L#1342 should just be {code}if (stmt.usesSecondaryIndexes && stmt.keyIsInRelation){code} > 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.1.5#6160)