[
https://issues.apache.org/jira/browse/CASSANDRA-11067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15130989#comment-15130989
]
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:
{code}
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' WITH OPTIONS = {'mode' :
'CONTAINS'};
{code}
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:
{code}
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"
{code}
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:
{code}
if (isLIKE())
return String.format("%s %s", entityAsString, relationType);
{code}
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 SASI.md, 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: 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)
