[
https://issues.apache.org/jira/browse/CASSANDRA-4851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne updated CASSANDRA-4851:
----------------------------------------
Attachment: 4851.txt
Attaching rather simple patch for this.
The patch implements the tuple/vector syntax described above (so {{WHERE (c1,
c2) > (1, 0)}} typically) as that's the easier and imo the most natural syntax
anyway when you want to do such a thing.
> CQL3: improve support for paginating over composites
> ----------------------------------------------------
>
> Key: CASSANDRA-4851
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4851
> Project: Cassandra
> Issue Type: Improvement
> Reporter: 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)
