[
https://issues.apache.org/jira/browse/CASSANDRA-11043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15128755#comment-15128755
]
Sam Tunnicliffe commented on CASSANDRA-11043:
---------------------------------------------
[~adelapena], sorry about the slow response - you're right though, the
intention is to validate those expressions earlier and reject before getting to
the point of execution. Unfortunately, the unit test covering that is not
properly representative of running on a real server so it didn't catch the
problem you described. I think we also need to add back the early validation of
non-custom expressions, as although the custom expression syntax is a better
fit for indexes which don't map to a specific column, for backwards
compatibility it's still possible to do things in the old style, by creating a
fake column & adding an index on it. The fix should be reasonably
straightforward, but I'd like to have a think about how to test this better
(using custom indexes etc in dtests is not so straightforward). I'll aim to
have a patch ready sometime this week.
> Secondary indexes doesn't properly validate custom expressions
> --------------------------------------------------------------
>
> Key: CASSANDRA-11043
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11043
> Project: Cassandra
> Issue Type: Bug
> Components: CQL, Local Write-Read Paths
> Reporter: Andrés de la Peña
> Labels: 21, index, validation
> Attachments: test-index.zip
>
>
> It seems that
> [CASSANDRA-7575|https://issues.apache.org/jira/browse/CASSANDRA-7575] is
> broken in Cassandra 3.x. As stated in the secondary indexes' API
> documentation, custom index implementations should perform any validation of
> query expressions at {{Index#searcherFor(ReadCommand)}}, throwing an
> {{InvalidRequestException}} if the expressions are not valid. I assume these
> validation errors should produce an {{InvalidRequest}} error on cqlsh, or
> raise an {{InvalidQueryException}} on Java driver. However, when
> {{Index#searcherFor(ReadCommand)}} throws its {{InvalidRequestException}}, I
> get this cqlsh output:
> {noformat}
> Traceback (most recent call last):
> File "bin/cqlsh.py", line 1246, in perform_simple_statement
> result = future.result()
> File
> "/Users/adelapena/stratio/platform/src/cassandra-3.2.1/bin/../lib/cassandra-driver-internal-only-3.0.0-6af642d.zip/cassandra-driver-3.0.0-6af642d/cassandra/cluster.py",
> line 3122, in result
> raise self._final_exception
> ReadFailure: code=1300 [Replica(s) failed to execute read] message="Operation
> failed - received 0 responses and 1 failures" info={'failures': 1,
> 'received_responses': 0, 'required_responses': 1, 'consistency': 'ONE'}
> {noformat}
> I attach a dummy index implementation to reproduce the error:
> {noformat}
> CREATE KEYSPACE test with replication = {'class' : 'SimpleStrategy',
> 'replication_factor' : '1' };
> CREATE TABLE test.test (id int PRIMARY KEY, value varchar);
> CREATE CUSTOM INDEX test_index ON test.test() USING 'com.stratio.TestIndex';
> SELECT * FROM test.test WHERE expr(test_index,'ok');
> SELECT * FROM test.test WHERE expr(test_index,'error');
> {noformat}
> This is specially problematic when using Cassandra Java Driver, because one
> of these server exceptions can produce subsequent queries fail (even if they
> are valid) with a no host available exception.
> Maybe the validation method added with
> [CASSANDRA-7575|https://issues.apache.org/jira/browse/CASSANDRA-7575] should
> be restored, unless there is a way to properly manage the exception.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
