[
https://issues.apache.org/jira/browse/CASSANDRA-11617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15249886#comment-15249886
]
Andrés de la Peña edited comment on CASSANDRA-11617 at 4/20/16 1:38 PM:
------------------------------------------------------------------------
An additional problem with producing {{SinglePartitionReadCommand}} is that
queries using the {{IN}} operator to be directed to a limited set of nodes are
not invoking the method {{postProcessorFor}}, which is called from
{{SinglePartitionReadCommand.postReconciliationProcessing}}. So, for example,
the following top-k query over a limited set of partitions will produce wrong
results due to the lack of post processing:
{code}
CREATE TABLE messages (user text, bucket int, id UUID, body text, PRIMARY KEY
((user, bucket), id)) ;
SELECT * FROM messages WHERE expr(idx, 'sort_by_body_relevance') AND user =
'sam' AND bucket IN (1,2,3) LIMIT 10;
{code}
Also the lack of custom index expression validation with
{{SinglePartitionReadCommand}} makes imposible to detect the problem at index
level. We are using a custom query handler to avoid this kind of queries but it
would be great to be able to process them. IMHO, partition-directed queries
give a lot of sense to 2i in several use cases. What do you think? Should we
open a new ticket for this?
was (Author: adelapena):
An additional problem with producing {{SinglePartitionReadCommand}} is that
queries using the {{IN}} operator to be directed to a limited set of nodes are
not invoking the method {{postProcessorFor}}, which is called from
{{SinglePartitionReadCommand.postReconciliationProcessing}}. So, for example,
the following top-k queries over a limited set of partitions will produce wrong
results due to the lack of post processing:
{code}
CREATE TABLE messages (user text, bucket int, id UUID, body text, PRIMARY KEY
((user, bucket), id)) ;
SELECT * FROM messages WHERE expr(idx, '{}') AND user = 'sam' AND bucket IN
(1,2,3) LIMIT 10;
{code}
Also the lack of custom index expression validation with
{{SinglePartitionReadCommand}} makes imposible to detect the problem at index
level. We are using a custom query handler to avoid this kind of queries but it
would be great to be able to process them. IMHO, partition-directed queries
give a lot of sense to 2i in several use cases. What do you think? Should we
open a new ticket for this?
> The presence of custom index expressions doesn't set the indexing flag in
> StatementRestrictions
> -----------------------------------------------------------------------------------------------
>
> Key: CASSANDRA-11617
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11617
> Project: Cassandra
> Issue Type: Bug
> Components: CQL
> Reporter: Sam Tunnicliffe
> Assignee: Sam Tunnicliffe
> Fix For: 3.0.x, 3.x
>
>
> This can lead to queries with index expressions being executed as single
> partition rather than partition range reads, which should always be the case
> for index queries, even when the partition key is restricted.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
