[
https://issues.apache.org/jira/browse/CASSANDRA-19764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17865472#comment-17865472
]
Branimir Lambov commented on CASSANDRA-19764:
---------------------------------------------
{quote}the write will timeout at QUORUM consistency, as expected.
{quote}
In other words, TCM makes it practically impossible to run into the situation
this test is meant to exercise?
Coming back to
{quote}it seems like a bad idea to allow altering UDTs once they are part of a
primary key...
{quote}
Adding a new field to a UDT key is actually okay, we treat old values as
shorter and can correctly order them, as long as we know all the types.
But there may be a short amount of time where a replica does not yet know the
type of the added field (likely only really a thing before TCM). If it then
accepts a write without knowing the types as it currently does, it can corrupt
itself. It makes sense to just reject this write, even more so if TCM or
something else prevents schemas from going out of sync altogether.
> Corruption can occur while a field is being added to UDT clustering key
> -----------------------------------------------------------------------
>
> Key: CASSANDRA-19764
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19764
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/UDT
> Reporter: Branimir Lambov
> Priority: Normal
>
> CASSANDRA-15938 made some improvements in how unknown components in UDTs are
> treated. Unfortunately this can cause corruption as soon as more than one
> value is inserted for a partition.
> The problem can be easily shown by modifying the
> {{FrozenUDTTest.testDivergentSchema}} test to insert two entries in the wrong
> order:
> {code:java}
> cluster.coordinator(1).execute("insert into " + KEYSPACE + ".x (id, ck, i)
> VALUES (?, " + json(1, 2) + ", ? )", ConsistencyLevel.ALL,
> 1, 2);
> cluster.coordinator(1).execute("insert into " + KEYSPACE + ".x (id, ck, i)
> VALUES (?, " + json(1, 1) + ", ? )", ConsistencyLevel.ALL,
> 1, 1);
> {code}
> after which we can get corrupted sstable state, shown as a
> {code:java}
> java.lang.AssertionError: Lower bound [SSTABLE_LOWER_BOUND(1) ]is bigger than
> first returned value [Row: ck=1 | i=2]
> {code}
> exception, or results like {{[[1],[2],[2],[1]]}} or {{[[2],[1],[2]]}} for
> {{select i from x WHERE id = 1}} depending on which node we use as
> coordinator.
> Because we don't know the type of new fields and cannot properly order
> entries, we need to outright reject UDT keys that are not compatible with a
> replica's schema.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
