[
https://issues.apache.org/jira/browse/CASSANDRA-15938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17199950#comment-17199950
]
Alex Petrov commented on CASSANDRA-15938:
-----------------------------------------
[~maedhroz] thank you for checking! we could do that, but I have left it as-is
for now. Main motivation for not changing it is withouot storing all potential
duplicates, we'd only say how many duplicates were different to the first
clustering we've seen, which is only partially useful. That said, if you
already have duplicates, you probably should take a close look at your sstables
anyways.
I've committed the change to 2.2 with
[2f0eb6f799f32c6f01d1f8384d48910c34ff6a98|https://github.com/apache/cassandra/commit/2f0eb6f799f32c6f01d1f8384d48910c34ff6a98]
and merged it up to
[3.0|https://github.com/apache/cassandra/commit/2cde7a7e148e333c3cac7a015322db5f7ccbe6c5],
[3.11|https://github.com/apache/cassandra/commit/492009ae9b48839cc97540ecb1cf5217c1f30118]
and
[trunk|https://github.com/apache/cassandra/commit/53234e744db432666dc27625f87258ce6aab2d23]
with corresponding changes.
> 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]
