[ https://issues.apache.org/jira/browse/CASSANDRA-15938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17170438#comment-17170438 ]
Caleb Rackliffe commented on CASSANDRA-15938: --------------------------------------------- [~ifesdjeen] After looking at the 3.0+ patches, the basic fix looks reasonable. There are only two things that seem worth mentioning: - It seems like {{allRemainingComponentsAreNull()}} corrected the previous mistake of potentially treating a size of zero as null, but it doesn't look like there was a test that covered this case. Not sure how important it is for us to add that, but it's worth considering. - The extra bit of diagnostic information in {{DuplicateRowChecker}} might be useful, but I'm not sure exactly how much overhead the extra {{equals()}} check will introduce on compaction and read. +1 otherwise > Fix support for adding UDT fields to clustering keys > ---------------------------------------------------- > > Key: CASSANDRA-15938 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15938 > Project: Cassandra > Issue Type: Bug > Components: Feature/UDT > Reporter: Alex Petrov > Assignee: Alex Petrov > Priority: Normal > Fix For: 2.2.x, 3.0.x, 3.11.x, 4.0-beta > > > Adding UDT fields to clustering keys is broken in all versions, however > slightly differently. > In 4.0, there will be a brief moment while schema changes are propagated > during which we won’t be able to decode and compare byte sequences. > Unfortunately, it is unclear what we should do in such cases, since we can’t > just come up with a comparator, and we can’t ignore non-null trailing values, > since this will lead to cases where compare for tuples `a;1` and `a;2` would > return 0, effectively making them equal, and we don’t know how to compare > unknown trailing values. Probably we should reject such query since we can’t > sort correctly, but we should make the error message more descriptive than > just "Index 1 out of bounds for length 1”. The only problem is that we get > this exception only on flush right now, so data already propagates to the > node by that time. > In 3.0, the problem is a bit worse than that, since in 3.0 we do not ignore > trailing nulls, so some of the values, written before `ALTER TYPE .. ADD` > become inaccessible. Both old values, and the new ones should always be > accessible. -- This message was sent by Atlassian Jira (v8.3.4#803005) --------------------------------------------------------------------- To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org