cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sam Tunnicliffe (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-11067) Improve SASI syntax
Date Thu, 04 Feb 2016 11:34:39 GMT

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

Mime
View raw message