cassandra-commits mailing list archives

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

    [ https://issues.apache.org/jira/browse/CASSANDRA-11067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15131828#comment-15131828
] 

Pavel Yaskevich commented on CASSANDRA-11067:
---------------------------------------------

bq. Isn't that the difference between LIKE 'term' and LIKE 'term%' ?

It is a _currently_ a difference, but it's not exactly the point but rather that `LIKE 'term'`
is essentially but not necessarily `= 'term'` and definitely not vice versa, for example LIKE
'<term>' and = '<term>' would be completely different meaning for indexes which
support fuzzy matching, hence I'm against the idea of enforcing LIKE 'term' vs. = 'term' which
locks-in index implementers and backend into the certain not flexible framework, the same
way as current assumption that everything is separated by AND does.

I can add additional MATCHES type to Operator class instead of converting LIKE '<term>'
to Operator.EQ but SASI indexes would always implement both EQ and MATCH as well as PREFIX,
CONTAINS, SUFFIX depending on the index type, so I'm not sure how useful it's going to be
in the current situation. 

> 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