It looks like there are a couple of things going on here. The type check
when adding a UDT column:
new_type.isValueCompatibleWith(dropped_type)
will only be true if the dropped type is a UDT. This however will never be
the case, since UDT types are replaced with tuple when converted to a
dropped column type.
Though re-adding the UDT should be safe, it will not always be safe. Since
there is currently no way to record a non-frozen tuple, a frozen and
non-frozen UDT will both produce the same dropped column type (leading
to CASSANDRA-14673). So it is technically safer to reject the add (though
the table would already be corrupted and this would keep you from fixing
it).
However, there are some inconsistencies. Had this check used the
(presumably stricter) isCompatibleWith check, it would have passed since it
treats both as tuple type. Also, you are able to re-add the column as a
tuple, which would be incompatible with non-frozen UDT data.
On Thu, Nov 21, 2019 at 5:59 AM Tommy Stendahl
<tommy.stend...@ericsson.com.invalid> wrote:
> Hi,
>
> I run in to problem with 3.11.5, I think its related to "* Toughen up
> column drop/recreate type validations (CASSANDRA-15204)"
>
> I have a user defined type and I have a table with a column that has this
> UDF as type, if I drop the column and recreate it with the same name it
> fails. I think this should work, it did in 3.11.4, or I'm I missing
> something?
>
> I recreated this in cqlsh:
>
> cqlsh> CREATE KEYSPACE foo WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> CREATE TYPE foo.my_type (a int, b int );
> cqlsh> CREATE TABLE foo.bar ( x int PRIMARY KEY, y int, z frozen<my_type>
> );
> cqlsh> ALTER TABLE foo.bar DROP z ;
> cqlsh> ALTER TABLE foo.bar ADD z frozen<my_type>;
> InvalidRequest: Error from server: code=2200 [Invalid query]
> message="Cannot re-add previously dropped column 'z' of type
> frozen<my_type>, incompatible with previous type frozen<tuple<int, int>>"
> cqlsh>
>
> Regards,
> Tommy
>
