cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Petrov (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-7017) allow per-partition LIMIT clause in cql
Date Wed, 06 Apr 2016 12:02:25 GMT


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: 

> allow per-partition LIMIT clause in cql
> ---------------------------------------
>                 Key: CASSANDRA-7017
>                 URL:
>             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,
> 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

View raw message