[
https://issues.apache.org/jira/browse/CASSANDRA-11067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15131597#comment-15131597
]
Pavel Yaskevich commented on CASSANDRA-11067:
---------------------------------------------
bq. Not sure what you mean. You can always use LIKE 'term' where you could use
= 'term', right? So just use LIKE and leave = for untokenized (and numeric)
comparison.
The point I'm trying to make - there is no way to tell what analyzer would do
with the data, which means that every time analyzer is set on the field I need
to force all of the queries to use LIKE instead of "=" that doesn't really make
a lot of sense if analyzer/tokenizer doesn't do anything special with the data
e.g. it's simply down-cases it, I can make such change but the problem with it
is - index parameterization are going to directly affect requests, because
after adding analyzer, all of the previous "=" are just going to fail although
they might be still totally valid ones. I would also like to emphasize the
point that by just specifying 'mode' everything works in the "canonical" way -
"=" is strict equality and LIKE is like but as soon as users are going to start
playing with tokenization and other analyzer properties they would directly
become aware what would LIKE and "=" mean in the new context.
bq. Where is = the norm? Jon gave a good summary above for LIKE behavior, I can
add that none of those systems overload = for tokenization.
I'm more talking about free text search (something like Lucene/Solr) because
that's the only place where analyzers like stemming and tokenization are useful
which don't have a lot specific syntactic constructs (e.g. ":") but use
something which is effectively an "=" in most of the analyzer/tokenization
involved situations.
> 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)
