[
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: [email protected]
For additional commands, e-mail: [email protected]
