Details
-
Bug
-
Status: Resolved
-
Normal
-
Resolution: Fixed
-
None
-
Correctness
-
Low
-
Normal
-
Code Inspection
-
All
-
None
-
Description
LWT conditions behaviour on collections is inconsistent in several ways around null values:
1)Conditions comparing a collection column with a null value to a non-null have a different behaviour for frozen and non-frozen collection.
UPDATE myTable SET l = ? WHERE k = 0 IF l < [1, 2]
If l is null the previous query will return [false, null] for a frozen collection and [true] for a non-frozen collection.
2) Conditions on non-frozen collection treat empty differently from null
Due to the way multi-cell collections are implemented, it is not possible to differentiate between null and empty collections like it is feasible for single cell (frozen) collections. Therefore an empty multi-cell collection will always be treated as null.
Unfortunately, the way LWT conditions handle that is not consistent with that.
For example for colA list<int> non null:
.. IF colA >= null
will throw an invalid request error whereas
..IF colA >= []
will returns true.
Moreover, if we insert an empty list through:
INSERT INTO mytable (pk, colA) VALUES (1, []);
and use
DELETE FROM mytable WHERE pk=1 IF colA = []
the returned results will be
{false, null}
. Which can be quite confusing.
The way to fix that behaviour to make it consistent with other operations is to consider empty multi-cell collection input as null and reject the null input for non = and != operators.
Attachments
Issue Links
- blocks
-
CASSANDRA-19620 Refactor ColumnCondition post CASSANDRA-19341
-
- Review In Progress
-
- links to
