[jira] [Comment Edited] (CASSANDRA-15353) Documentation Preview - Cassandra 4.0
[ https://issues.apache.org/jira/browse/CASSANDRA-15353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16949783#comment-16949783 ] DeepakVohra edited comment on CASSANDRA-15353 at 10/16/19 1:11 AM: --- TODOs --- Please review and add comments to documentation preview. *Backups* https://docs.google.com/document/d/1Inc0oxprLYpsd2RRMhoriwaekH2Wh5w2HYpmaDUnLTs/edit?usp=sharing *Bulk Loading* https://docs.google.com/document/d/1hBzipNML9ym7jPVs99yW0XFaZiXsjb5pCpMQti9J4PY/edit?usp=sharing *Data Definition* https://docs.google.com/document/d/17GY5Ax2HFB5MpMgokg8K8UBD4HwuwinBXYhXmHS0gZ0/edit?usp=sharing *Data Modeling* https://docs.google.com/document/d/1cQxZ2X3cCcpTN1cswg4-UozQ6FJeClwkcLy_7dz8YhY/edit?usp=sharing *Dynamo* https://docs.google.com/document/d/1iJyzFWpNbYVVrforVzbZh7Phv_ZMW6phBqzu9_CDhrA/edit?usp=sharing *Guarantees* https://docs.google.com/document/d/1Jmou6yGp4yoqaa4j3VS1pMLEUG9ipuFCKpRYMXUgcxI/edit?usp=sharing *Hints* https://docs.google.com/document/d/1ywJCvWMuUzdtNjLDtwoM6agan0fc9Pu4v9CCiYrz1FU/edit?usp=sharing *Read Repair* https://docs.google.com/document/d/1qkyXPAYjkb2fFAP5WAOJ9KGTrRQ79Cl4nhuydf0m03U/edit?usp=sharing *Full Repair Example* https://docs.google.com/document/d/1Hxncmze_KNhpDQjrvePMfhGnspZEuwW8tqgqrMAMp4Q/edit?usp=sharing was (Author: dvohra): TODOs --- Please review and add comments to documentation preview. *Dynamo* https://docs.google.com/document/d/1iJyzFWpNbYVVrforVzbZh7Phv_ZMW6phBqzu9_CDhrA/edit?usp=sharing *Read Repair* https://docs.google.com/document/d/1qkyXPAYjkb2fFAP5WAOJ9KGTrRQ79Cl4nhuydf0m03U/edit?usp=sharing *Full Repair Example* https://docs.google.com/document/d/1Hxncmze_KNhpDQjrvePMfhGnspZEuwW8tqgqrMAMp4Q/edit?usp=sharing *Hints* https://docs.google.com/document/d/1ywJCvWMuUzdtNjLDtwoM6agan0fc9Pu4v9CCiYrz1FU/edit?usp=sharing *Backups* https://docs.google.com/document/d/1Inc0oxprLYpsd2RRMhoriwaekH2Wh5w2HYpmaDUnLTs/edit?usp=sharing *Bulk Loading* https://docs.google.com/document/d/1hBzipNML9ym7jPVs99yW0XFaZiXsjb5pCpMQti9J4PY/edit?usp=sharing *Guarantees* https://docs.google.com/document/d/1Jmou6yGp4yoqaa4j3VS1pMLEUG9ipuFCKpRYMXUgcxI/edit?usp=sharing *Data Definition* https://docs.google.com/document/d/17GY5Ax2HFB5MpMgokg8K8UBD4HwuwinBXYhXmHS0gZ0/edit?usp=sharing > Documentation Preview - Cassandra 4.0 > - > > Key: CASSANDRA-15353 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15353 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: DeepakVohra >Priority: Normal > > Please review, and add comments to, some of the documentation preview for > Apache Cassandra 4.0. > New Features > --- > *Support for Java 11* > https://docs.google.com/document/d/1v7ffccqk_5Son4iwfuwZae8YUam41quewKi_6Z_PQGw/edit?usp=sharing > Improvements > > *Improved Streaming* > https://docs.google.com/document/d/1zd6AuHBgC82v598cuDtVIkxJVDV9c0A2rrMEVFHyB4Y/edit?usp=sharing > *Improved Internode Messaging* > https://docs.google.com/document/d/1ub2DBHE7hNEKe4tuCOpdbCZ7qGqCdMAYvSTC-YamuMA/edit?usp=sharing -- 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
[jira] [Comment Edited] (CASSANDRA-15169) SASIIndex does not compare strings correctly
[
https://issues.apache.org/jira/browse/CASSANDRA-15169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16952124#comment-16952124
]
Michael Semb Wever edited comment on CASSANDRA-15169 at 10/15/19 6:07 PM:
--
[~mazhenlin], if you look through the docs at
https://github.com/apache/cassandra/blob/trunk/doc/SASI.md you see a few
different use-cases.
I've updated the unit tests to go through more of these use-cases.
bq. there are many restrictions in the code for not applying RANGE on literal
indexes(e.g. ColumnIndex.supports)…
thanks for pointing that out. agreed, using "ALLOW FILTERING" isn't exactly
testing the index, but the at least it's testing that the index doesn't do that
query and the results that will be returned otherwise. nonetheless, i've
updated the tests (my branches listed above) to verify when the index will work
(and won't).
was (Author: michaelsembwever):
[~mazhenlin], if you look through the docs at
https://github.com/apache/cassandra/blob/trunk/doc/SASI.md you see a few
different use-cases.
I've updated the unit tests to go through more of these use-cases.
bq. there are many restrictions in the code for not applying RANGE on literal
indexes(e.g. ColumnIndex.supports)…
thanks for pointing that out. agreed, using "ALLOW FILTERING" isn't exactly
testing the index, but the at least it's testing that the index doesn't do that
query and the results that will be returned otherwise. nonetheless, i've
updated the tests to verify when the index will work (and won't).
> 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
[jira] [Updated] (CASSANDRA-15356) CassandraEntireSSTableStreamWriter throws IOException rather than FSError for disk issues so doesn't get handled by disk failing policy
[ https://issues.apache.org/jira/browse/CASSANDRA-15356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-15356: -- Description: Found while testing CASSANDRA-15332 Streaming relies on the CassandraDaemon's setup of Thread.setDefaultUncaughtExceptionHandler for the disk failure policy, which relies on FSError being thrown; org.apache.cassandra.db.streaming.CassandraEntireSSTableStreamWriter doesn't re-throw IOExceptions as FSError, so this path won't properly handle the disk failure policy. was: Found while testing CASSANDRA-15332 Streaming relies on the CassandraDaemon's setup of Thread.setDefaultUncaughtExceptionHandler for the disk failure policy, which relies on FSError being thrown. > CassandraEntireSSTableStreamWriter throws IOException rather than FSError for > disk issues so doesn't get handled by disk failing policy > --- > > Key: CASSANDRA-15356 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15356 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Streaming >Reporter: David Capwell >Priority: Normal > > Found while testing CASSANDRA-15332 > Streaming relies on the CassandraDaemon's setup of > Thread.setDefaultUncaughtExceptionHandler for the disk failure policy, which > relies on FSError being thrown; > org.apache.cassandra.db.streaming.CassandraEntireSSTableStreamWriter doesn't > re-throw IOExceptions as FSError, so this path won't properly handle the disk > failure policy. -- 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
[jira] [Updated] (CASSANDRA-15356) CassandraEntireSSTableStreamWriter throws IOException rather than FSError for disk issues so doesn't get handled by disk failing policy
[ https://issues.apache.org/jira/browse/CASSANDRA-15356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-15356: -- Description: Found while testing CASSANDRA-15332 Streaming relies on the CassandraDaemon's setup of Thread.setDefaultUncaughtExceptionHandler for the disk failure policy, which relies on FSError being thrown. was: Found while testing CASSANDRA-15332 When streaming sees a IOException (in ChannelProxy), this gets converted to a FSReadError but the stream logic doesn’t call the disk failure policy so will not be properly handled. > CassandraEntireSSTableStreamWriter throws IOException rather than FSError for > disk issues so doesn't get handled by disk failing policy > --- > > Key: CASSANDRA-15356 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15356 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Streaming >Reporter: David Capwell >Priority: Normal > > Found while testing CASSANDRA-15332 > Streaming relies on the CassandraDaemon's setup of > Thread.setDefaultUncaughtExceptionHandler for the disk failure policy, which > relies on FSError being thrown. -- 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
[jira] [Updated] (CASSANDRA-15356) CassandraEntireSSTableStreamWriter throws IOException rather than FSError for disk issues so doesn't get handled by disk failing policy
[ https://issues.apache.org/jira/browse/CASSANDRA-15356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-15356: -- Summary: CassandraEntireSSTableStreamWriter throws IOException rather than FSError for disk issues so doesn't get handled by disk failing policy (was: When streaming throws a FSError the DiskFailurePolicy does not get applied) > CassandraEntireSSTableStreamWriter throws IOException rather than FSError for > disk issues so doesn't get handled by disk failing policy > --- > > Key: CASSANDRA-15356 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15356 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Streaming >Reporter: David Capwell >Priority: Normal > > Found while testing CASSANDRA-15332 > When streaming sees a IOException (in ChannelProxy), this gets converted to a > FSReadError but the stream logic doesn’t call the disk failure policy so will > not be properly handled. -- 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
[jira] [Commented] (CASSANDRA-15356) When streaming throws a FSError the DiskFailurePolicy does not get applied
[ https://issues.apache.org/jira/browse/CASSANDRA-15356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16952172#comment-16952172 ] David Capwell commented on CASSANDRA-15356: --- Changing the description and title. Turns out that the disk failing policy is handled by CassandraDaemon and that dtests don't set that up properly so the stream tests had a false positive. I am repurposing this jira to now be "CassandraEntireSSTableStreamWriter throws IOException rather than FSError for disk issues, so doesn't get handled by disk failing policy" > When streaming throws a FSError the DiskFailurePolicy does not get applied > -- > > Key: CASSANDRA-15356 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15356 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Streaming >Reporter: David Capwell >Priority: Normal > > Found while testing CASSANDRA-15332 > When streaming sees a IOException (in ChannelProxy), this gets converted to a > FSReadError but the stream logic doesn’t call the disk failure policy so will > not be properly handled. -- 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
[jira] [Comment Edited] (CASSANDRA-15169) SASIIndex does not compare strings correctly
[
https://issues.apache.org/jira/browse/CASSANDRA-15169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16952124#comment-16952124
]
Michael Semb Wever edited comment on CASSANDRA-15169 at 10/15/19 5:43 PM:
--
[~mazhenlin], if you look through the docs at
https://github.com/apache/cassandra/blob/trunk/doc/SASI.md you see a few
different use-cases.
I've updated the unit tests to go through more of these use-cases.
bq. there are many restrictions in the code for not applying RANGE on literal
indexes(e.g. ColumnIndex.supports)…
thanks for pointing that out. agreed, using "ALLOW FILTERING" isn't exactly
testing the index, but the at least it's testing that the index doesn't do that
query and the results that will be returned otherwise. nonetheless, i've
updated the tests to verify when the index will work (and won't).
was (Author: michaelsembwever):
[~mazhenlin], if you look through the docs at
https://github.com/apache/cassandra/blob/trunk/doc/SASI.md you see a few
different use-cases.
I've updated the unit tests to go through more of these use-cases.
bq. there are many restrictions in the code for not applying RANGE on literal
indexes(e.g. ColumnIndex.supports)…
thanks for pointing that out. agreed, using "ALLOW FILTERING" isn't exactly
testing the index, but the at least it's testing that the index doesn't do that
query and the results that will be returned otherwise. nonetheless, i've
updated the tests to verify when the index will work.
> 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
[jira] [Comment Edited] (CASSANDRA-15169) SASIIndex does not compare strings correctly
[
https://issues.apache.org/jira/browse/CASSANDRA-15169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16952124#comment-16952124
]
Michael Semb Wever edited comment on CASSANDRA-15169 at 10/15/19 5:43 PM:
--
[~mazhenlin], if you look through the docs at
https://github.com/apache/cassandra/blob/trunk/doc/SASI.md you see a few
different use-cases.
I've updated the unit tests to go through more of these use-cases.
bq. there are many restrictions in the code for not applying RANGE on literal
indexes(e.g. ColumnIndex.supports)…
thanks for pointing that out. agreed, using "ALLOW FILTERING" isn't exactly
testing the index, but the at least it's testing that the index doesn't do that
query and the results that will be returned otherwise. nonetheless, i've
updated the tests to verify when the index will work.
was (Author: michaelsembwever):
[~mazhenlin], if you look through the docs at
https://github.com/apache/cassandra/blob/trunk/doc/SASI.md you see a few
different use-cases.
I've updated the unit tests to go through more of these use-cases.
bq. there are many restrictions in the code for not applying RANGE on literal
indexes(e.g. ColumnIndex.supports)…
thanks for pointing that out. i'm still getting my head around that. in the
meantime we can figure out where {{forceFlush}} results in different behaviour,
as that's the obvious breakages to deal with…
> 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
[jira] [Created] (CASSANDRA-15357) test org.apache.cassandra.config.DatabaseDescriptorRefTest#testDatabaseDescriptorRef constantly failing on trunk
David Capwell created CASSANDRA-15357: - Summary: test org.apache.cassandra.config.DatabaseDescriptorRefTest#testDatabaseDescriptorRef constantly failing on trunk Key: CASSANDRA-15357 URL: https://issues.apache.org/jira/browse/CASSANDRA-15357 Project: Cassandra Issue Type: Bug Components: Test/unit Reporter: David Capwell See https://circleci.com/gh/dcapwell/cassandra/84#tests/containers/1 and https://circleci.com/gh/dcapwell/cassandra/85#tests/containers/1 I see that this test is failing on trunk with the following junit.framework.AssertionFailedError at org.apache.cassandra.config.DatabaseDescriptorRefTest.checkViolations(DatabaseDescriptorRefTest.java:293) at org.apache.cassandra.config.DatabaseDescriptorRefTest.testDatabaseDescriptorRef(DatabaseDescriptorRefTest.java:277) Seems related to https://issues.apache.org/jira/browse/CASSANDRA-12677 -- 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
[jira] [Comment Edited] (CASSANDRA-15169) SASIIndex does not compare strings correctly
[
https://issues.apache.org/jira/browse/CASSANDRA-15169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16952124#comment-16952124
]
Michael Semb Wever edited comment on CASSANDRA-15169 at 10/15/19 5:26 PM:
--
[~mazhenlin], if you look through the docs at
https://github.com/apache/cassandra/blob/trunk/doc/SASI.md you see a few
different use-cases.
I've updated the unit tests to go through more of these use-cases.
bq. there are many restrictions in the code for not applying RANGE on literal
indexes(e.g. ColumnIndex.supports)…
thanks for pointing that out. i'm still getting my head around that. in the
meantime we can figure out where {{forceFlush}} results in different behaviour,
as that's the obvious breakages to deal with…
was (Author: michaelsembwever):
[~mazhenlin], if you look through the docs at
https://github.com/apache/cassandra/blob/trunk/doc/SASI.md you see a few
different use-cases.
It looks like we have broken the "equals queries perform prefix searches" on
non-literal NORMAL indexes. See the "Equality & Prefix Queries" section.
I've update the unit tests to go through more of these use-cases.
bq. there are many restrictions in the code for not applying RANGE on literal
indexes(e.g. ColumnIndex.supports)…
thanks for pointing that out. i'm still getting my head around that. in the
meantime we can figure out where {{forceFlush}} results in different behaviour,
as that's the obvious breakages to deal with…
> 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
[jira] [Commented] (CASSANDRA-15169) SASIIndex does not compare strings correctly
[
https://issues.apache.org/jira/browse/CASSANDRA-15169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16952124#comment-16952124
]
Michael Semb Wever commented on CASSANDRA-15169:
[~mazhenlin], if you look through the docs at
https://github.com/apache/cassandra/blob/trunk/doc/SASI.md you see a few
different use-cases.
It looks like we have broken the "equals queries perform prefix searches" on
non-literal NORMAL indexes. See the "Equality & Prefix Queries" section.
I've update the unit tests to go through more of these use-cases.
bq. there are many restrictions in the code for not applying RANGE on literal
indexes(e.g. ColumnIndex.supports)…
thanks for pointing that out. i'm still getting my head around that. in the
meantime we can figure out where {{forceFlush}} results in different behaviour,
as that's the obvious breakages to deal with…
> 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
[jira] [Updated] (CASSANDRA-15332) When building MerkleTrees if a CorruptSSTableException is thrown the DiskFailurePolicy does not get applied
[ https://issues.apache.org/jira/browse/CASSANDRA-15332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-15332: -- Reviewers: Blake Eggleston, Marcus Eriksson (was: Marcus Eriksson) > When building MerkleTrees if a CorruptSSTableException is thrown the > DiskFailurePolicy does not get applied > --- > > Key: CASSANDRA-15332 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15332 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Repair >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > > When a repair is in the validation phase and is building MerkleTrees, if a > corrupt SSTable exception is thrown the disk failure policy does not get > applied -- 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
[jira] [Comment Edited] (CASSANDRA-15169) SASIIndex does not compare strings correctly
[
https://issues.apache.org/jira/browse/CASSANDRA-15169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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
[jira] [Commented] (CASSANDRA-15169) SASIIndex does not compare strings correctly
[
https://issues.apache.org/jira/browse/CASSANDRA-15169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16951778#comment-16951778
]
mazhenlin commented on CASSANDRA-15169:
---
[~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
[jira] [Updated] (CASSANDRA-15332) When building MerkleTrees if a CorruptSSTableException is thrown the DiskFailurePolicy does not get applied
[ https://issues.apache.org/jira/browse/CASSANDRA-15332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-15332: Reviewers: Marcus Eriksson > When building MerkleTrees if a CorruptSSTableException is thrown the > DiskFailurePolicy does not get applied > --- > > Key: CASSANDRA-15332 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15332 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Repair >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > > When a repair is in the validation phase and is building MerkleTrees, if a > corrupt SSTable exception is thrown the disk failure policy does not get > applied -- 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
