[
https://issues.apache.org/jira/browse/CASSANDRA-11067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15131714#comment-15131714
]
Pavel Yaskevich commented on CASSANDRA-11067:
---------------------------------------------
I disagree on both points, so let me clarify:
bq. Again, if you want to avoid that, you can use LIKE instead, which will
change behavior to match the index by design. Whereas equals does not, also by
design.
This is not true - since PREFIX index can and does match both - EQ and PREFIX
queries so '=' query makes sense to use there since it's - give me only results
completely matching string N without accounting for case sensitivity, where
LIKE query makes no sense in that context because LIKE effectively means
"matching" and not "exact".
bq. I think that where the behavior of databases and search systems conflict we
should prefer to act like a database.
I disagree, because basically what you are saying here - we don't want
analyzers, but they are essential for operation of indexes like SASI which can
do both - indexing and search and each of the columns is considered a
collection of indexable terms that can be intersected together with other
columns via the set of unifying row ids.
Which brings us to the bigger point - if we want to control how/what indexes do
we should not provide a pluggable API so people can build their on but if we do
we should respect decisions that authors took since that is an opt-in feature.
> 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)
