[
https://issues.apache.org/jira/browse/CASSANDRA-15169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16951778#comment-16951778
]
mazhenlin edited comment on CASSANDRA-15169 at 10/15/19 9:57 AM:
-----------------------------------------------------------------
[~mck] , since there are many restrictions in the code for not applying RANGE
on literal indexes(e.g. ColumnIndex.supports), I have never considered the
operation in your new case. Now if we want to remove these restrictions for
PREFIX mode, the followings need to be done:
1 The expected results of OnDiskIndexTest.testNotEqualsQueryForStrings need to
be changed because it is conflicted between the common '>' semantic and using
NEQ as "not-like-prefix".
2 Make OnDiskIndex behaves correctly in comparison. This can be done easily.
3 Support RANGE for MemIndex. This might be a little complicated. Since the
TrieMemIndex does not support RANGE ,we need to either implement our new
radix-tree class to support RANGE operation , or use SkipListMemIndex for
PREFIX mode and treat "a like b% " as " a > b and a < bytes(b)+1 ".
Besides, obviously RANGE operations are meaningful only for untokenized
indexes. We need to think about whether these changes are worthwhile, and
whether they will confuse users.
was (Author: mazhenlin):
[~mck] , since there are many restrictions in the code for not applying RANGE
on literal indexes(e.g. ColumnIndex.supports), I have never considered the
operation in your new case. Now if we want to remove these restrictions for
PREFIX mode, the followings need to be done:
1 The expected results of OnDiskIndexTest.testNotEqualsQueryForStrings need to
be changed because it is conflicted between the common '>' semantic and using
NEQ as "not-like-prefix".
2 Make OnDiskIndex behaves correctly in comparison. This can be done easily.
3 Support RANGE for MemIndex. This might be a little complicated. Since the
TrieMemIndex does not support RANGE right now ,we need to either implement our
new radix-tree class to support RANGE operation , or use SkipListMemIndex for
PREFIX mode and treat "a like b% " as " a > b and a < bytes(b)+1 ".
Besides, obviously RANGE operations are meaningful only for untokenized
indexes. We need to think about whether these changes are worthwhile, and
whether they will confuse users.
> SASIIndex does not compare strings correctly
> --------------------------------------------
>
> Key: CASSANDRA-15169
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15169
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/SASI
> Reporter: mazhenlin
> Assignee: mazhenlin
> Priority: Normal
> Attachments: CASSANDRA-15169-v1.patch, CASSANDRA-15169-v2.patch
>
>
> In our scenario, we need to query with '>' conditions on string columns. So I
> created index with is_literal = false. like the following:
>
> {code:java}
> CREATE TABLE test (id int primary key, t text);
> CREATE CUSTOM INDEX ON test (t) USING
> 'org.apache.cassandra.index.sasi.SASIIndex' WITH OPTIONS = {'is_literal':
> 'false'};
> {code}
> I also inserted some records and query:
>
> {code:java}
> insert into test(id,t) values(1,'abc');
> select * from test where t > 'ab';
> {code}
> At first ,it worked. But after flush, the query returned none record.
> I have read the code of SASIIndex and found that it is because in the
> {code:java}
> Expression.isLowerSatisfiedBy{code}
> function,
> {code:java}
> term.compareTo{code}
> was called with parameter checkFully=false, which cause the string 'abc' was
> only compared with its first 2 characters( length of expression value).
>
> I have wrote a UT for this case and fixed it.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
