[ https://issues.apache.org/jira/browse/CASSANDRA-15203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Aleksey Yeschenko updated CASSANDRA-15203: ------------------------------------------ Source Control Link: [08b2192da0eb6deddcd8f79cd180d069442223ae|https://github.com/apache/cassandra/commit/08b2192da0eb6deddcd8f79cd180d069442223ae] Since Version: 4.0 Status: Resolved (was: Ready to Commit) Resolution: Fixed Cheers, committed as [08b2192da0eb6deddcd8f79cd180d069442223ae|https://github.com/apache/cassandra/commit/08b2192da0eb6deddcd8f79cd180d069442223ae] > Fix AlterTableStatement dropped type validation order > ----------------------------------------------------- > > Key: CASSANDRA-15203 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15203 > Project: Cassandra > Issue Type: Bug > Components: Cluster/Schema > Reporter: Aleksey Yeschenko > Assignee: Aleksey Yeschenko > Priority: Normal > Fix For: 4.0 > > > 4.0 has a minor bug in AlterTableStatement, in which we compare value > compatibility of dropped type with new type instead of the other way around > (and order is significant here). > This results in more conversions identified as valid than should be allowed > to. > The fix is a trivial one-liner. > Relatedly, we should audit all implementations of {{isValueCompatible()}} out > there - at least one, {{BytesType}} - is no longer valid in 3.0+, since > {{BytesType}} can no longer correctly read any complex column. And perhaps go > even further, and restrict column recreation to only previously dropped type > *precisely*, for which I have a couple arguments as well. > That said, I'd like to defer those to a different ticket. -- This message was sent by Atlassian JIRA (v7.6.3#76005) --------------------------------------------------------------------- To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org