[ https://issues.apache.org/jira/browse/CASSANDRA-10723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15011327#comment-15011327 ]
Sylvain Lebresne commented on CASSANDRA-10723: ---------------------------------------------- bq. Changing the name of a UDT field or changing its type may or may not break a UDF/UDA functions. Maybe I'm being paranoid, but that's a problem in my opinion. I do think we might want to stick to what is done in CASSANDRA-10721 and forbid renames in UDT that is used in declared UDF/UDA completely. If people really want to rename, they'll have to drop the UDF/UDA, do the rename, and re-declare the UDF/UDA, which isn't super convenient, but it's still better imo than having the rename silently breaking functions (which will force you to re-declare the functions anyway). > 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)