[
https://issues.apache.org/jira/browse/CASSANDRA-11067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15117501#comment-15117501
]
Jack Krupansky commented on CASSANDRA-11067:
--------------------------------------------
Awesome! Watch out, SQL!
One more nit...
The fact that a SASI index needs to be "CUSTOM" and an explicit class name is
needed feels a little hokey to me. Is there a longer-term plan to fully
integrate SASI so it is a first-class feature rather than simply an add-on? In
fact, is there any reason not to make it the default secondary indexing (other
than the fact that is new and experimental and unproven in the real world yet)?
Having the mode be a keyword rather than all this extra lexical distraction
would feel better to me.
But if this is billed as experimental in 3.4, maybe there is no real harm in
deferring first-class status until a future feature release.
Still, it would be nice to be able to say CREATE PREFIX INDEX or CREATE SUFFIX
INDEX or CREATE SPARSE INDEX.
> 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)
