[jira] [Updated] (CASSANDRA-19479) Fix type issues and provide tests for type compatibility between 4.1 and 5.0
[ https://issues.apache.org/jira/browse/CASSANDRA-19479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-19479: --- Fix Version/s: 5.0-beta2 5.0 (was: 5.0-rc) > Fix type issues and 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: Legacy/Core, Test/unit >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 4.0.13, 4.1.5, 5.0-beta2, 5.0, 5.1 > > Attachments: ci_summary.html, results_details.tar.xz > > > 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
[jira] [Updated] (CASSANDRA-19479) Fix type issues and provide tests for type compatibility between 4.1 and 5.0
[ https://issues.apache.org/jira/browse/CASSANDRA-19479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacek Lewandowski updated CASSANDRA-19479: -- Fix Version/s: 4.0.13 4.1.5 5.0-rc 5.1 (was: 5.x) (was: 4.0.x) (was: 4.1.x) (was: 5.0.x) Source Control Link: https://github.com/apache/cassandra/commit/f92998190ccfc688e22d035318848a2f61987585 Resolution: Fixed Status: Resolved (was: Ready to Commit) > Fix type issues and 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: Legacy/Core, Test/unit >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 4.0.13, 4.1.5, 5.0-rc, 5.1 > > Attachments: ci_summary.html, results_details.tar.xz > > > 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
[jira] [Updated] (CASSANDRA-19479) Fix type issues and provide tests for type compatibility between 4.1 and 5.0
[ https://issues.apache.org/jira/browse/CASSANDRA-19479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacek Lewandowski updated CASSANDRA-19479: -- Attachment: results_details.tar.xz ci_summary.html > Fix type issues and 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: Legacy/Core, Test/unit >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x > > Attachments: ci_summary.html, results_details.tar.xz > > > 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
[jira] [Updated] (CASSANDRA-19479) Fix type issues and provide tests for type compatibility between 4.1 and 5.0
[ https://issues.apache.org/jira/browse/CASSANDRA-19479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacek Lewandowski updated CASSANDRA-19479: -- Status: Ready to Commit (was: Review In Progress) > Fix type issues and 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: Legacy/Core, Test/unit >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x > > Attachments: ci_summary.html, results_details.tar.xz > > > 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
[jira] [Updated] (CASSANDRA-19479) Fix type issues and provide tests for type compatibility between 4.1 and 5.0
[ https://issues.apache.org/jira/browse/CASSANDRA-19479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacek Lewandowski updated CASSANDRA-19479: -- Reviewers: Stefan Miklosovic Status: Review In Progress (was: Patch Available) > Fix type issues and 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: Legacy/Core, Test/unit >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x > > > 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
[jira] [Updated] (CASSANDRA-19479) Fix type issues and provide tests for type compatibility between 4.1 and 5.0
[ https://issues.apache.org/jira/browse/CASSANDRA-19479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19479: -- Fix Version/s: 4.0.x 4.1.x 5.0.x 5.x (was: 5.0) (was: 5.1) (was: 4.1.5) (was: 4.0.13) > Fix type issues and 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: Legacy/Core, Test/unit >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x > > > 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
[jira] [Updated] (CASSANDRA-19479) Fix type issues and provide tests for type compatibility between 4.1 and 5.0
[ https://issues.apache.org/jira/browse/CASSANDRA-19479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacek Lewandowski updated CASSANDRA-19479: -- Component/s: Legacy/Core > Fix type issues and 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: Legacy/Core, 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
[jira] [Updated] (CASSANDRA-19479) Fix type issues and provide tests for type compatibility between 4.1 and 5.0
[ https://issues.apache.org/jira/browse/CASSANDRA-19479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacek Lewandowski updated CASSANDRA-19479: -- Summary: Fix type issues and provide tests for type compatibility between 4.1 and 5.0 (was: Provide tests for type compatibility between 4.1 and 5.0) > Fix type issues and 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