[
https://issues.apache.org/jira/browse/CASSANDRA-11067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15132190#comment-15132190
]
Sam Tunnicliffe commented on CASSANDRA-11067:
---------------------------------------------
bq. Regarding validation for index options you've mentioned I'm not really sure
by what means we are going to accomplish that
Fair enough, comprehensive validation at index creation is difficult without
knowing or limiting the set of expected queries. The pressing problem I see is
that the choice of MemIndex implementation (goverened by whether the indexed
terms are considered literals) constrains the supported operations. Because its
underlying trie doesn't support range operations, TrieMemIndex rejects range
queries by throwing an UnsupportedOperationException at execution time.
Although this is slightly different to the problem described in
CASSANDRA-11043, the outcome is the same:
{code}
cqlsh> create table ks.t1(k int primary key, v int);
cqlsh> create custom index prefix_idx on ks.t1(v) using
'org.apache.cassandra.index.sasi.SASIIndex' with options = { 'mode':'PREFIX',
'is_literal':'true'};
cqlsh> select * from ks.t1 where v > 0;
Traceback (most recent call last):
File "bin/cqlsh.py", line 1250, in perform_simple_statement
result = future.result()
File
"/home/sam/projects/cassandra/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'}
{code}
I played with simply extending ColumnIndex to return false if {{isLiteral() &&
op == RANGE}} which fixes this specific problem. My concern is that that may be
others that I haven't considered, wdyt?
A couple of other, minor things (sorry, I missed these earlier):
Log messages generated during flush are generally written at DEBUG level now
(and so don't appear in system.log with the default config). There are a few
related messages from SASI still logged at INFO, can those be switched to DEBUG?
One more nit in the docs: *IndexMemtable* section still refers to {{NORMAL}}
and {{SUFFIX}} indexing modes.
> Improve SASI syntax
> -------------------
>
> Key: CASSANDRA-11067
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11067
> Project: Cassandra
> Issue Type: Task
> Components: CQL
> Reporter: Jonathan Ellis
> Assignee: Pavel Yaskevich
> Fix For: 3.4
>
>
> I think everyone agrees that a LIKE operator would be ideal, but that's
> probably not in scope for an initial 3.4 release.
> Still, I'm uncomfortable with the initial approach of overloading = to mean
> "satisfies index expression." The problem is that it will be very difficult
> to back out of this behavior once people are using it.
> I propose adding a new operator in the interim instead. Call it MATCHES,
> maybe. With the exact same behavior that SASI currently exposes, just with a
> separate operator rather than being rolled into =.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
