[ 
https://issues.apache.org/jira/browse/CASSANDRA-11067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15132838#comment-15132838
 ] 

Pavel Yaskevich commented on CASSANDRA-11067:
---------------------------------------------

[~beobal] 

bq. Fair enough, comprehensive validation at index creation is difficult 
without knowing or limiting the set of expected queries.

I think 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.

bq. Log messages generated during flush are generally written at DEBUG level 
now (and so don't appear in system.log with the default config). There are a 
few related messages from SASI still logged at INFO, can those be switched to 
DEBUG?

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, that's 
the only things which are currently logged.

bq. One more nit in the docs: IndexMemtable section still refers to NORMAL and 
SUFFIX indexing modes.

Can you please point me exactly where it is because I don't see it anywhere and 
grep doesn't show anything in the CASSANDRA-11067 branch.



> 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)

Reply via email to