[ https://issues.apache.org/jira/browse/CASSANDRA-15169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16948391#comment-16948391 ]
mazhenlin commented on CASSANDRA-15169: --------------------------------------- [~mck] Thank you for your comments. I went deeper and found that I had made some mistakes before. Since isSatisfiedBy will be called for every record in term later, it is acceptable to incorrectly include a term by isUpperSatisfiedBy/isLowerSatisfiedBy, but omitting a term incorrectly is not acceptable. I was wrong about isUpperSatisfiedBy. The checkFully=false is required for the LIKE_PREFIX operator because otherwise term could be omitted by isUpperSatisfiedBy incorrectly. But for the GT operator, checkFully need to be true in isLowerSatisfiedBy and isUpperSatisfiedBy( for ReversedType ). The OnDiskIndexTest.testNotEqualsQueryForStrings failed because it uses NEQ as "not like" semantic. So I think it should work to set checkFully=true only for RANGE operator and only when is_literal=false( to retain the "not like" semantic of NEQ) . > 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 > > > 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