[
https://issues.apache.org/jira/browse/CASSANDRA-11067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15117681#comment-15117681
]
Jordan West commented on CASSANDRA-11067:
-----------------------------------------
bq. other than the fact that is new and experimental and unproven in the real
world yet?
I think SASI is as, or more, proven than any change in the 3.x releases. Its
been in production for longer than any 3.x feature and most of the changes for
3.x were surface-level integration changes as [~xedin] mentioned.
bq. The fact that a SASI index needs to be "CUSTOM" and an explicit class name
is needed feels a little hokey to me.
Agreed but we decided not to change this to ease the merge and because the
sstable's format is not extendable easily, currently. Also, this the case for
any non-default index class. I think it would be great to SASI become the
default implementation or to have an easier way to specify which implementation
to use.
> 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)
