[
https://issues.apache.org/jira/browse/CASSANDRA-21761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18133509#comment-18133509
]
Mohammad Suhel commented on CASSANDRA-21761:
--------------------------------------------
Hi, I'd like to take this one.
I reproduced it on the latest cassandra-5.0. It is not limited to a top-level
frozen<udt>: a UDT nested in a collection is also rejected. For example,
dropping and re-adding a list<frozen<udt>> column fails with (test type name
shortened to udt):
{noformat}
Cannot add a column 'x' of type list<frozen<udt>>, incompatible with previously
dropped column 'x' of type list<frozen<tuple<int, text>>>{noformat}
I agree with the analysis. One caveat on just expanding the new type before the
check: {{expandUserTypes()}} turns a non-frozen UDT into a frozen tuple. So
after dropping a {{frozen<udt>}} column, \{{ALTER TABLE ... ADD x udt}}
(non-frozen) would pass the multi-cell check and be accepted. That is a
simple/complex mismatch, which CASSANDRA-16905 explicitly disallows. I verified
this locally: with only the expansion, the non-frozen re-add is accepted. I
plan to compare the expanded type for value compatibility, but compare
{{isMultiCell()}} on the original type.
{{LegacySSTableTest.testVerifyOldDroppedTupleSSTables}} currently expects the
re-add of {{val3}} (a {{frozen<legacy_*_tuple_udt>}} column) to be rejected.
That expectation was added in CASSANDRA-20485, and
with the fix the re-add succeeds, so I'll update the test as part of the patch.
[~mck], [~dnk], could you confirm the rejection there was just recording the
existing behaviour rather than something intended?
I'll prepare the patch against cassandra-5.0 and merge it forward to 6.0 and
trunk.
> Re-adding a dropped column with the same frozen user type is rejected as
> incompatible
> -------------------------------------------------------------------------------------
>
> Key: CASSANDRA-21761
> URL: https://issues.apache.org/jira/browse/CASSANDRA-21761
> Project: Apache Cassandra
> Issue Type: Bug
> Components: Legacy/Local Write-Read Paths
> Reporter: Nadav Har'El
> Assignee: Mohammad Suhel
> Priority: Normal
> Fix For: 5.0.x, 6.x, 7.x
>
>
> After dropping a column of a frozen user type, re-adding a column with the
> same name and the *same* type fails:
> {code:sql}
> CREATE TYPE ks.udt (a int, b text);
> CREATE TABLE ks.t (p int PRIMARY KEY, x frozen<udt>);
> ALTER TABLE ks.t DROP x;
> ALTER TABLE ks.t ADD x frozen<udt>;
> {code}
> The last statement fails with:
> {noformat}
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Cannot
> add a column 'x' of type frozen<udt>, incompatible with previously dropped
> column 'x' of type frozen<tuple<int, text>>"
> {noformat}
> Reproduced on Cassandra 5.0.9 and 6.0-alpha2.
> The cause: a dropped column's type is recorded with its user types expanded
> into tuples ({{TableMetadata}}, {{column.type.expandUserTypes()}}), but
> {{AlterTableStatement}} compares the new, unexpanded type with it using
> {{isSerializationCompatibleWith()}}, and a {{UserType}} is not
> value-compatible with a {{TupleType}}. Expanding the new type the same way
> before the comparison would fix it.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
