cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sam Tunnicliffe (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-11067) Improve SASI syntax
Date Wed, 03 Feb 2016 19:43:40 GMT


Sam Tunnicliffe commented on CASSANDRA-11067:

Mostly lgtm, I think there's just a couple of things:

We need some validation of the index options with respect to the type of the target column.
For instance:
CREATE TABLE ks.t1(k int, v int, PRIMARY KEY(k));
CREATE CUSTOM INDEX v_contains_index on ks.t1(v) USING 'org.apache.cassandra.index.sasi.SASIIndex'

This happily creates an index which can be queried using EQ, but not with LT/LTE/GT/GTE (in
contrast to the one created if OPTIONS is ommitted). Of course, LIKE can't work for this index
either. I don't think this is a showstopper, but it is somewhat counterintuitive for users.
I'd be ok with leaving this for now if you'd rather open a ticket with broader scope to cover
any/all validation we need to add, otherwise let's just address this particular instance now.

This is very minor, but the error message is a little awkward when you try to execute a prefix/suffix
match on an index which doesn't support that:
cqlsh> select * from ks.t1 where name LIKE 'Pav%';
InvalidRequest: code=2200 [Invalid query] message="name LIKE '<term>%' 'Pav' restriction
is only supported on properly indexed columns"

I don't think having the actual term value there is particularly useful (and interpolating
it into the Operator string is fiddly) , so perhaps a specialisation in {{SingleColumnRelation}}
like the one for {{isIN}} would work:
if (isLIKE())
    return String.format("%s %s", entityAsString, relationType);

Suffix matching doesn't seem to have the same level of coverage in SASIIndexTest as prefix
and contains. Do you think it's worth adding anything, just for clarity if nothing else?

Finally, in, there's a couple of minor nits:

bq. The semantics of CQL's = were modified instead of making further modifications of the
grammar with the introduction of a LIKE operator. Ideally, CQL would be modified to include
such an operator, supporting both prefix and suffix searches.
can be removed

References to {{Indexer}} in "The SASIIndex Class" section should be to {{Searcher}}, right?

*Limitations and Caveats* refers to the "lack of LIKE"

> Improve SASI syntax
> -------------------
>                 Key: CASSANDRA-11067
>                 URL:
>             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

View raw message