[
https://issues.apache.org/jira/browse/CASSANDRA-15938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Petrov updated CASSANDRA-15938:
------------------------------------
Test and Documentation Plan: Tests attached.
Status: Patch Available (was: Open)
|[2.2 patch|https://github.com/ifesdjeen/cassandra/tree/15938-2.2]|[2.2
CI|https://circleci.com/gh/ifesdjeen/cassandra/tree/15938-2.2]|
|[3.0 patch|https://github.com/ifesdjeen/cassandra/tree/15938-3.0]|[3.0
CI|https://circleci.com/gh/ifesdjeen/cassandra/tree/15938-3.0]|
|[3.11 patch|https://github.com/ifesdjeen/cassandra/tree/15938-3.11]|[3.11
CI|https://circleci.com/gh/ifesdjeen/cassandra/tree/15938-3.11]|
|[trunk patch|https://github.com/ifesdjeen/cassandra/tree/15938-trunk]|[trunk
CI|https://circleci.com/gh/ifesdjeen/cassandra/tree/15938-trunk]|
> 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: 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]
