Uploaded image for project: 'Cassandra'
  1. Cassandra
  2. CASSANDRA-19479

Fix type issues and provide tests for type compatibility between 4.1 and 5.0

Agile BoardAttach filesAttach ScreenshotBulk Copy AttachmentsBulk Move AttachmentsVotersWatch issueWatchersCreate sub-taskConvert to sub-taskMoveLinkCloneLabelsUpdate Comment AuthorReplace String in CommentUpdate Comment VisibilityDelete Comments
    XMLWordPrintableJSON

Details

    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

      Attachments

        1. results_details.tar.xz
          2.49 MB
          Jacek Lewandowski
        2. ci_summary.html
          1.94 MB
          Jacek Lewandowski

        Activity

          This comment will be Viewable by All Users Viewable by All Users
          Cancel

          People

            jlewandowski Jacek Lewandowski Assign to me
            jlewandowski Jacek Lewandowski
            Jacek Lewandowski
            Stefan Miklosovic
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Slack

                Issue deployment