[
https://issues.apache.org/jira/browse/CASSANDRA-11067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15133903#comment-15133903
]
Sam Tunnicliffe commented on CASSANDRA-11067:
---------------------------------------------
bq. what we probably will end up doing is instead of 'mode' we'll ask users to
specify what kind of operations do the want to perform and based on that pick
the mode internally, but let's maybe leave this to a separate issue since it's
unclear yet what the interface is going to be.
A separate issue for figuring out the long term solution is great, but I really
think that not giving users a crappy experience out of the box in cases where
we can easily avoid it is a good idea. Is there a problem with not allowing
range queries on literals that I've overlooked?
bq. Flushing/Loading of the indexes is intentionally left at INFO to give
operators more visibility into what is going on and how much time do things take
Ok, that's reasonable.
bq. Can you please point me exactly where it is because I don't see it anywhere
Sorry, my bad I had the original docs open in an old browser tab. smdh
> 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)
