[
https://issues.apache.org/jira/browse/CASSANDRA-7017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15228156#comment-15228156
]
Alex Petrov commented on CASSANDRA-7017:
----------------------------------------
Great! Thanks for review!
I've made the changes you've mentioned:
* made {{SelectStatement.getLimit}} {{public}} again and removed {{static}}
there and in {{prepareLimit}}. There was no need to make them static. I'm
sometimes marking methods as static if they play utility role. Although in this
case it was more behavioural, my bad.
* switched to {{boolean}} variable for {{useCompactStorage}} in tests
* made {{DISTINCT}} queries with {{PER PARTITION LIMIT}} throw
{{InvalidRequestException}}
* as regards {{assertRowsIgnoringOrder}}, I've switched to it overall. The
only case it can not cover is when we combine {{PER PARTITION LIMIT}} and
"global" {{LIMIT}}, since we don't know which partitions are going to be
returned. I've switched to verification of resut set size for now. Even
ignoring {{extra}} and {{missing}} within {{assertRowsIgnoringOrder}} wouldn't
help here, since for every query we will end up with both extra and missing, so
in the end it'll be same.
Unfortunately, still no CI for me, hope to get it whenever US morning comes. V2
is attached and branch is updated:
|[trunk|https://github.com/ifesdjeen/cassandra/tree/7017-trunk]|
> 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: Alex Petrov
> Labels: cql
> Fix For: 3.x
>
> Attachments: 0001-Allow-per-partition-limit-in-SELECT-queries.patch,
> 0001-Allow-per-partition-limit-in-SELECT-queriesV2.patch,
> 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)
