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