[
https://issues.apache.org/jira/browse/CASSANDRA-18576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Piotr Kolaczkowski updated CASSANDRA-18576:
-------------------------------------------
Description:
During working on CEP-29, I found that single-column and multi-column
clustering restrictions are not merged correctly and cause query failures or
incorrect results.
Reproduction:
{code}
createTable("CREATE TABLE %s (pk int, c1 int, c2 int, v int, primary
key(pk, c1, c2)) WITH CLUSTERING ORDER BY (c1 DESC, c2 ASC)");
execute("INSERT INTO %s (pk, c1, c2, v) values (?, ?, ?, ?)", 1, 0, 1,
11);
execute("INSERT INTO %s (pk, c1, c2, v) values (?, ?, ?, ?)", 1, 0, 2,
12);
execute("INSERT INTO %s (pk, c1, c2, v) values (?, ?, ?, ?)", 1, 0, 3,
13);
execute("INSERT INTO %s (pk, c1, c2, v) values (?, ?, ?, ?)", 1, 0, 4,
14);
execute("INSERT INTO %s (pk, c1, c2, v) values (?, ?, ?, ?)", 1, 1, 1,
21);
execute("INSERT INTO %s (pk, c1, c2, v) values (?, ?, ?, ?)", 1, 1, 2,
22);
execute("INSERT INTO %s (pk, c1, c2, v) values (?, ?, ?, ?)", 1, 1, 3,
23);
execute("INSERT INTO %s (pk, c1, c2, v) values (?, ?, ?, ?)", 1, 1, 4,
24);
assertRows(execute("SELECT * FROM %s WHERE pk = ? AND c1 < ? AND (c1,
c2) > ?",
1, tuple(0, 1), 1),
row(1, 0, 2, 12),
row(1, 0, 3, 13),
row(1, 0, 4, 14));
{code}
In this particular case the message is:
{noformat}
org.apache.cassandra.serializers.MarshalException: Not enough bytes to read 0th
component
at org.apache.cassandra.db.marshal.TupleType.split(TupleType.java:312)
at org.apache.cassandra.db.marshal.TupleType.split(TupleType.java:286)
at
org.apache.cassandra.cql3.Tuples$Value.fromSerialized(Tuples.java:156)
at org.apache.cassandra.cql3.Tuples$Marker.bind(Tuples.java:398)
at org.apache.cassandra.cql3.Tuples$Marker.bind(Tuples.java:386)
at
org.apache.cassandra.cql3.restrictions.MultiColumnRestriction$SliceRestriction.componentBounds(MultiColumnRestriction.java:527)
at
org.apache.cassandra.cql3.restrictions.MultiColumnRestriction$SliceRestriction.appendBoundTo(MultiColumnRestriction.java:390)
at
org.apache.cassandra.cql3.restrictions.ClusteringColumnRestrictions.boundsAsClustering(ClusteringColumnRestrictions.java:134)
at
org.apache.cassandra.cql3.restrictions.StatementRestrictions.getClusteringColumnsBounds(StatementRestrictions.java:783)
at
org.apache.cassandra.cql3.statements.SelectStatement.makeSlices(SelectStatement.java:737)
at
org.apache.cassandra.cql3.statements.SelectStatement.makeClusteringIndexFilter(SelectStatement.java:716)
at
org.apache.cassandra.cql3.statements.SelectStatement.getSliceCommands(SelectStatement.java:616)
at
org.apache.cassandra.cql3.statements.SelectStatement.getQuery(SelectStatement.java:315)
at
org.apache.cassandra.cql3.statements.SelectStatement.executeInternal(SelectStatement.java:483)
at
org.apache.cassandra.cql3.statements.SelectStatement.executeLocally(SelectStatement.java:469)
at
org.apache.cassandra.cql3.statements.SelectStatement.executeLocally(SelectStatement.java:97)
{noformat}
If you reorder the restrictions so that the restriction (c1, c2) > ? comes
before the single column restriction on c1, the test passes.
The algorithm used in {{RestrictionSet.mergeRestrictions}} is incorrect, as its
results depend on the (undefined) order of restrictions in a hashset.
In more complex scenarios, when there are more restrictions to merge, the
algorithm results can even differ between the test runs.
Reproduced on trunk, commit b07c3127cce7e1a8b9d4c34e1359539e12f1b4a7 .
was:
During working on CEP-29, I found that single-column and multi-column
clustering restrictions are not merged correctly and cause query failures or
incorrect results.
Reproduction:
{code}
createTable("CREATE TABLE %s (pk int, c1 int, c2 int, v int, primary
key(pk, c1, c2)) WITH CLUSTERING ORDER BY (c1 DESC, c2 ASC)");
execute("INSERT INTO %s (pk, c1, c2, v) values (?, ?, ?, ?)", 1, 0, 1,
11);
execute("INSERT INTO %s (pk, c1, c2, v) values (?, ?, ?, ?)", 1, 0, 2,
12);
execute("INSERT INTO %s (pk, c1, c2, v) values (?, ?, ?, ?)", 1, 0, 3,
13);
execute("INSERT INTO %s (pk, c1, c2, v) values (?, ?, ?, ?)", 1, 0, 4,
14);
execute("INSERT INTO %s (pk, c1, c2, v) values (?, ?, ?, ?)", 1, 1, 1,
21);
execute("INSERT INTO %s (pk, c1, c2, v) values (?, ?, ?, ?)", 1, 1, 2,
22);
execute("INSERT INTO %s (pk, c1, c2, v) values (?, ?, ?, ?)", 1, 1, 3,
23);
execute("INSERT INTO %s (pk, c1, c2, v) values (?, ?, ?, ?)", 1, 1, 4,
24);
assertRows(execute("SELECT * FROM %s WHERE pk = ? AND c1 < ? AND (c1,
c2) > ?",
1, tuple(0, 1), 1),
row(1, 0, 2, 12),
row(1, 0, 3, 13),
row(1, 0, 4, 14));
{code}
In this particular case the message is:
{noformat}
org.apache.cassandra.serializers.MarshalException: Not enough bytes to read 0th
component
at org.apache.cassandra.db.marshal.TupleType.split(TupleType.java:312)
at org.apache.cassandra.db.marshal.TupleType.split(TupleType.java:286)
at
org.apache.cassandra.cql3.Tuples$Value.fromSerialized(Tuples.java:156)
at org.apache.cassandra.cql3.Tuples$Marker.bind(Tuples.java:398)
at org.apache.cassandra.cql3.Tuples$Marker.bind(Tuples.java:386)
at
org.apache.cassandra.cql3.restrictions.MultiColumnRestriction$SliceRestriction.componentBounds(MultiColumnRestriction.java:527)
at
org.apache.cassandra.cql3.restrictions.MultiColumnRestriction$SliceRestriction.appendBoundTo(MultiColumnRestriction.java:390)
at
org.apache.cassandra.cql3.restrictions.ClusteringColumnRestrictions.boundsAsClustering(ClusteringColumnRestrictions.java:134)
at
org.apache.cassandra.cql3.restrictions.StatementRestrictions.getClusteringColumnsBounds(StatementRestrictions.java:783)
at
org.apache.cassandra.cql3.statements.SelectStatement.makeSlices(SelectStatement.java:737)
at
org.apache.cassandra.cql3.statements.SelectStatement.makeClusteringIndexFilter(SelectStatement.java:716)
at
org.apache.cassandra.cql3.statements.SelectStatement.getSliceCommands(SelectStatement.java:616)
at
org.apache.cassandra.cql3.statements.SelectStatement.getQuery(SelectStatement.java:315)
at
org.apache.cassandra.cql3.statements.SelectStatement.executeInternal(SelectStatement.java:483)
at
org.apache.cassandra.cql3.statements.SelectStatement.executeLocally(SelectStatement.java:469)
at
org.apache.cassandra.cql3.statements.SelectStatement.executeLocally(SelectStatement.java:97)
{noformat}
If you reorder the restrictions so that the restriction (c1, c2) > ? comes
before the single column restriction on c1, the test passes.
The algorithm used in {{RestrictionSet.mergeRestrictions}} is incorrect, as its
results depend on the (undefined) order of restrictions in a hashset.
In more complex scenarios, when there are more restrictions to merge, the
algorithm results can even differ between the test runs.
> Mixed single-column and multi-column clustering restrictions are not merged
> correctly
> -------------------------------------------------------------------------------------
>
> Key: CASSANDRA-18576
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18576
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
> Reporter: Piotr Kolaczkowski
> Assignee: Piotr Kolaczkowski
> Priority: Normal
>
> During working on CEP-29, I found that single-column and multi-column
> clustering restrictions are not merged correctly and cause query failures or
> incorrect results.
> Reproduction:
> {code}
> createTable("CREATE TABLE %s (pk int, c1 int, c2 int, v int, primary
> key(pk, c1, c2)) WITH CLUSTERING ORDER BY (c1 DESC, c2 ASC)");
> execute("INSERT INTO %s (pk, c1, c2, v) values (?, ?, ?, ?)", 1, 0,
> 1, 11);
> execute("INSERT INTO %s (pk, c1, c2, v) values (?, ?, ?, ?)", 1, 0,
> 2, 12);
> execute("INSERT INTO %s (pk, c1, c2, v) values (?, ?, ?, ?)", 1, 0,
> 3, 13);
> execute("INSERT INTO %s (pk, c1, c2, v) values (?, ?, ?, ?)", 1, 0,
> 4, 14);
> execute("INSERT INTO %s (pk, c1, c2, v) values (?, ?, ?, ?)", 1, 1,
> 1, 21);
> execute("INSERT INTO %s (pk, c1, c2, v) values (?, ?, ?, ?)", 1, 1,
> 2, 22);
> execute("INSERT INTO %s (pk, c1, c2, v) values (?, ?, ?, ?)", 1, 1,
> 3, 23);
> execute("INSERT INTO %s (pk, c1, c2, v) values (?, ?, ?, ?)", 1, 1,
> 4, 24);
>
> assertRows(execute("SELECT * FROM %s WHERE pk = ? AND c1 < ? AND (c1,
> c2) > ?",
> 1, tuple(0, 1), 1),
> row(1, 0, 2, 12),
> row(1, 0, 3, 13),
> row(1, 0, 4, 14));
> {code}
> In this particular case the message is:
> {noformat}
> org.apache.cassandra.serializers.MarshalException: Not enough bytes to read
> 0th component
> at org.apache.cassandra.db.marshal.TupleType.split(TupleType.java:312)
> at org.apache.cassandra.db.marshal.TupleType.split(TupleType.java:286)
> at
> org.apache.cassandra.cql3.Tuples$Value.fromSerialized(Tuples.java:156)
> at org.apache.cassandra.cql3.Tuples$Marker.bind(Tuples.java:398)
> at org.apache.cassandra.cql3.Tuples$Marker.bind(Tuples.java:386)
> at
> org.apache.cassandra.cql3.restrictions.MultiColumnRestriction$SliceRestriction.componentBounds(MultiColumnRestriction.java:527)
> at
> org.apache.cassandra.cql3.restrictions.MultiColumnRestriction$SliceRestriction.appendBoundTo(MultiColumnRestriction.java:390)
> at
> org.apache.cassandra.cql3.restrictions.ClusteringColumnRestrictions.boundsAsClustering(ClusteringColumnRestrictions.java:134)
> at
> org.apache.cassandra.cql3.restrictions.StatementRestrictions.getClusteringColumnsBounds(StatementRestrictions.java:783)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.makeSlices(SelectStatement.java:737)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.makeClusteringIndexFilter(SelectStatement.java:716)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.getSliceCommands(SelectStatement.java:616)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.getQuery(SelectStatement.java:315)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.executeInternal(SelectStatement.java:483)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.executeLocally(SelectStatement.java:469)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.executeLocally(SelectStatement.java:97)
> {noformat}
> If you reorder the restrictions so that the restriction (c1, c2) > ? comes
> before the single column restriction on c1, the test passes.
> The algorithm used in {{RestrictionSet.mergeRestrictions}} is incorrect, as
> its results depend on the (undefined) order of restrictions in a hashset.
> In more complex scenarios, when there are more restrictions to merge, the
> algorithm results can even differ between the test runs.
> Reproduced on trunk, commit b07c3127cce7e1a8b9d4c34e1359539e12f1b4a7 .
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
