[
https://issues.apache.org/jira/browse/CASSANDRA-11556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15237804#comment-15237804
]
Alex Petrov commented on CASSANDRA-11556:
-----------------------------------------
In this case patch should do as you say (skip {{PER PARTITION LIMIT}} if it's
aggregate, same as {{LIMIT}}, although allow {{PER PARTITION LIMIT}} when
post-query ordering is required).
|[trunk|https://github.com/ifesdjeen/cassandra/tree/11556-trunk]|[utest|https://cassci.datastax.com/view/Dev/view/ifesdjeen/job/ifesdjeen-11556-trunk-dtest/]|[dtest|https://cassci.datastax.com/view/Dev/view/ifesdjeen/job/ifesdjeen-11556-trunk-dtest/]|
> PER PARTITION LIMIT does not work properly for multi-partition query with
> ORDER BY
> ----------------------------------------------------------------------------------
>
> Key: CASSANDRA-11556
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11556
> Project: Cassandra
> Issue Type: Bug
> Reporter: Benjamin Lerer
> Assignee: Alex Petrov
> Fix For: 3.6
>
>
> Multi-partition queries with {{PER PARTITION LIMIT}} with {{ORDER BY}} do not
> respect the {{PER PARTITION LIMIT}}.
> The problem can be reproduced with the following unit test:
> {code}
> @Test
> public void testPerPartitionLimitWithMultiPartitionQueryAndOrderBy()
> throws Throwable
> {
> createTable("CREATE TABLE %s (a int, b int, c int, PRIMARY KEY (a,
> b))");
> for (int i = 0; i < 5; i++)
> {
> for (int j = 0; j < 5; j++)
> {
> execute("INSERT INTO %s (a, b, c) VALUES (?, ?, ?)", i, j, j);
> }
> }
> assertRows(execute("SELECT * FROM %s WHERE a IN (2, 3) ORDER BY b
> DESC PER PARTITION LIMIT ?", 2),
> row(2, 4, 4),
> row(3, 4, 4),
> row(2, 3, 3),
> row(3, 3, 3));
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
