[jira] [Comment Edited] (CASSANDRA-11617) The presence of custom index expressions doesn't set the indexing flag in StatementRestrictions

["Andrés de la Peña (JIRA)" <ji...@apache.org>]

    [ 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)