[ https://issues.apache.org/jira/browse/CASSANDRA-10723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15011396#comment-15011396 ]
Robert Stupp commented on CASSANDRA-10723: ------------------------------------------ No, it's not paranoia. It will break UDFs/UDAs, if the changed UDT field is used. Assume a UDF/UDA like this (no guarantee for correct syntax): {code} CREATE TYPE my_user_type ... udt_field int; CREATE FUNCTION state_fun ( arg my_user_type, col int ) ... AS $$ arg.setInt("udt_field", arg.getInt("udt_field") + col); return arg; $$; CREATE AGGREGATE user_aggr ... SFUNC state_fun INITCOND { udt_field: 0 }; {code} When issuing {{ALTER TYPE my_user_type RENAME udt_field TO foo;}}, the {{setInt}} and {{getInt}} calls will fail, because the field does not exist. Also for {{ALTER TYPE my_user_type ALTER udt_field DATE}}, the {{setInt}} and {{getInt}} calls will fail, because the field is not an {{int}}. > Rewrite INITCOND after renames and alters of UDT fields > ------------------------------------------------------- > > Key: CASSANDRA-10723 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10723 > Project: Cassandra > Issue Type: Improvement > Reporter: Robert Stupp > Priority: Minor > Fix For: 3.x > > > (Follow-up to CASSANDRA-10721) > In order to re-write an INITCOND value when a UDT is changed (component > renamed or type altered), we will have to check for broken aggregates first > (as we do not know why _exactly_ these are broken; CASSANDRA-10721 added > {{Function.isBroken()}}). > If one of the affected aggregates is broken, the request *must fail*. > If none of the affected aggregates is broken, we can re-write the binary > representation of the INITCOND and push schema migrations for these > aggregates. > Still unclear, if the user needs permissions on both the UDT _and_ the > affected UDAs for that. > Further, the UDT change and all UDA changes should be migrated in a single > mutation, which feels to be the biggest change. This is not a strict > requirement but would keep that schema change atomic. -- This message was sent by Atlassian JIRA (v6.3.4#6332)