[
https://issues.apache.org/jira/browse/CASSANDRA-20479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-20479:
--------------------------------------
Resolution: Won't Fix
Status: Resolved (was: Triage Needed)
confirmed this behavior existed in 4.1, so isn't a change in behavior.
> Inconsistent semantic when CAS condition is on a UDT column
> -----------------------------------------------------------
>
> Key: CASSANDRA-20479
> URL: https://issues.apache.org/jira/browse/CASSANDRA-20479
> Project: Apache Cassandra
> Issue Type: Bug
> Components: Feature/Lightweight Transactions
> Reporter: David Capwell
> Priority: Normal
>
> {code}
> @Test
> public void test() throws IOException
> {
> try (Cluster cluster = Cluster.build(1).start())
> {
> var inst = cluster.get(1);
> init(cluster);
> cluster.schemaChange(withKeyspace("CREATE TYPE %s.foo(f1 int)"));
> cluster.schemaChange(withKeyspace("CREATE TABLE %s.tbl(pk int, v0
> foo, v1 int, PRIMARY KEY(pk))"));
> inst.executeInternal(withKeyspace("INSERT INTO %s.tbl(pk, v1) VALUES
> (?, ?)"), 0, 0);
> AssertUtils.assertRows(inst.executeInternal(withKeyspace("SELECT *
> FROM %s.tbl WHERE v0=? ALLOW FILTERING"), ByteBufferUtil.EMPTY_BYTE_BUFFER),
> rows());
> }
> }
> {code}
> This fails with
> {code}
> org.apache.cassandra.exceptions.InvalidRequestException: Non-frozen UDT
> column 'v0' (foo) cannot be restricted by any relation
> at
> org.apache.cassandra.cql3.statements.RequestValidations.invalidRequest(RequestValidations.java:370)
> at
> org.apache.cassandra.cql3.statements.RequestValidations.checkTrue(RequestValidations.java:97)
> at
> org.apache.cassandra.cql3.statements.RequestValidations.checkFalse(RequestValidations.java:223)
> at org.apache.cassandra.cql3.Operator.validateFor(Operator.java:964)
> {code}
> But we allow this in a CAS condition
> {code}
> @Test
> public void test2() throws IOException
> {
> try (Cluster cluster = Cluster.build(1).start())
> {
> var coord = cluster.coordinator(1);
> init(cluster);
> cluster.schemaChange(withKeyspace("CREATE TYPE %s.foo(f1 int)"));
> cluster.schemaChange(withKeyspace("CREATE TABLE %s.tbl(pk int, v0
> foo, v1 int, PRIMARY KEY(pk))"));
> coord.execute(withKeyspace("UPDATE %s.tbl SET v1=? WHERE pk=? IF
> v0=?"), ConsistencyLevel.QUORUM, 0, 0, ByteBufferUtil.EMPTY_BYTE_BUFFER);
> AssertUtils.assertRows(coord.execute(withKeyspace("SELECT * FROM
> %s.tbl"), ConsistencyLevel.SERIAL),
> rows());
> }
> }
> {code}
> This test fails differently, it fails because the condition actually applied!
> {code}
> java.lang.AssertionError: Expected: []
> Actual: [[0, null, 0]]
> {code}
> The reason this happens is we don’t seem to validate the operations like we
> do in the WHERE clause, and
> org.apache.cassandra.cql3.Operator#isSatisfiedBy(org.apache.cassandra.db.marshal.MultiElementType<?>,
> org.apache.cassandra.db.rows.ComplexColumnData, java.nio.ByteBuffer) defines
> the following
> {code}
> if (elements.isEmpty())
> return leftOperand == null;
> {code}
> Since the row doesn’t exist, leftOperand is null, and elements is empty
> (tuple of null values != null logically).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
