[CASSANDRA-19479] Fix type issues and provide tests for type compatibility between 4.1 and 5.0 - ASF JIRA

XML

Word

Printable

JSON

Details

Type: Task
Status: Resolved
Priority: Normal
Resolution: Fixed
Fix Version/s: 4.0.13, 4.1.5, 5.0-rc1, 5.0, 5.1
Component/s: Legacy/Core, Test/unit
Labels:
None

Change Category:
Quality Assurance
Complexity:
Normal
Platform:

All
Impacts:

None
Source Control Link:

https://github.com/apache/cassandra/commit/f92998190ccfc688e22d035318848a2f61987585
Test and Documentation Plan:

Hide

regression tests

Show
regression tests

Description

This is a part of CASSANDRA-14476 - we should verify whether the type compatibility matrix is upgradable from 4.0 and 4.1 to 5.0, and if not, fix the remaining issues.

The implemented tests verify the following:

assumed compatibility between primitive types
equals method symmetricity
freezing/unfreezing
value compatibility by using a serializer of one type to deserialize a value serialized using a serializer of another type
serialization compatibility by serializing a row with a column of one type as a column of another type for simple and complex cells (multicell types)
(comparison) compatibility by comparing serialized values of one type using a comparator of another type; for multicell types - build rows and compare cell paths of a complex type using a cell path comparator of another complex type
verify whether types that are (value/serialization/comparison) compatible in a previous release are still compatible with this release
store the compatibility matrix in a compressed JSON file so that we can copy it to future releases to assert backward compatibility (similar approach to LegacySSTableTest)
verify that type serializers are different for non-compatible type pairs which use custom comparisons

Additionally:

the equals method in TupleType and UserType was fixed to be symmetric. Previously, comparing two values gave a different outcome when inverted.
fixed a condition in comparison method of AbstractCompositeType
ported a fix for composite and dynamic composite types which adds a distinct serializers for them so that the serializers for those types and for BytesType are considered different; similar thing was done for LexicalUUIDType to make its serializer different to UUIDType serializer (see https://the-asf.slack.com/archives/CK23JSY2K/p1712060572432959)
fixed a problem with DCT builder - in 5.0+ the DynamicCompositeType generation has a problem with inverse alias-type mapping which makes it vulnerable to problems when the same type has two different aliases