[
https://issues.apache.org/jira/browse/CASSANDRA-19479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacek Lewandowski updated CASSANDRA-19479:
------------------------------------------
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
was:
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)
Additionally, the equals method in TupleType and UserType was fixed to be
symmetric. Previously, comparing two values gave a different outcome when
inverted.
> Provide tests for type compatibility between 4.1 and 5.0
> --------------------------------------------------------
>
> Key: CASSANDRA-19479
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19479
> Project: Cassandra
> Issue Type: Task
> Components: Test/unit
> Reporter: Jacek Lewandowski
> Assignee: Jacek Lewandowski
> Priority: Normal
> Fix For: 4.0.13, 4.1.5, 5.0, 5.1
>
>
> 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
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
