[
https://issues.apache.org/jira/browse/CASSANDRA-7017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14156379#comment-14156379
]
Sylvain Lebresne commented on CASSANDRA-7017:
---------------------------------------------
Patch looks mostly good (and turns out simpler that I expected). The main point
that needs addressing is that we need to take the intra-node protocol version
into account when serializing/deserializing the new field in SliceQueryFilter.
Not sure what to do when writing a filter that has a static limit to an old
node, but we might just want to throw an error saying that you shouldn't use
static limits until your cluster is fully updated.
A few other minor remarks:
* Syntax wise, I suspect {{STATIC LIMIT}} (2 separated words) would be more
SQLy. In fact, while I bikesh on syntax, I wonder if {{STATIC}} couldn't make
some people think that the limit applies only to static columns or something
and maybe {{PARTITION LIMIT}} is a bit more explicit.
* In {{SelectStatement.getSliceCommands}}, I wouldn't use {{Math.min(limit,
staticLimit)}} for the {{count}}. It's not incorrect, but since we already do
that inside SliceQueryFilter, it's also unecessary so it feels like unecessary
inconsistency between the single partition and range cases.
* Could be nice to factor the code for {{getLimit}} and {{getStaticLimit}} in
{{SelectStatement}} a bit. Not a big deal though.
* Could you add tests that mix both a static/partition limit and a normal one?
> allow per-partition LIMIT clause in cql
> ---------------------------------------
>
> Key: CASSANDRA-7017
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7017
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Jonathan Halliday
> Assignee: Dan Burkert
> Labels: cql
> Fix For: 3.0
>
> Attachments: 0001-CASSANDRA-7017.patch
>
>
> somewhat related to static columns (#6561) and slicing (#4851), it is
> desirable to apply a LIMIT on a per-partition rather than per-query basis,
> such as to retrieve the top (most recent, etc) N clustered values for each
> partition key, e.g.
> -- for each league, keep a ranked list of users
> create table scores (league text, score int, player text, primary key(league,
> score, player) );
> -- get the top 3 teams in each league:
> select * from scores staticlimit 3;
> this currently requires issuing one query per partition key, which is tedious
> if all the key partition key values are known and impossible if they aren't.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
