[
https://issues.apache.org/jira/browse/CASSANDRA-19764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17865170#comment-17865170
]
Caleb Rackliffe commented on CASSANDRA-19764:
---------------------------------------------
So to be clear, this should reproduce on {{trunk}} as...
{noformat}
@Test
public void testDivergentSchemas() throws Throwable
{
try (Cluster cluster = init(Cluster.create(2)))
{
cluster.schemaChange("create type " + KEYSPACE + ".a (foo text)");
cluster.schemaChange("create table " + KEYSPACE + ".x (id int, ck
frozen<a>, i int, primary key (id, ck))");
cluster.filters().verbs(Verb.TCM_REPLICATION.id).drop().on();
cluster.coordinator(1).execute("alter type " + KEYSPACE + ".a add bar
text", ConsistencyLevel.QUORUM);
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);
cluster.get(2).flush(KEYSPACE);
Object[][] res1 = cluster.coordinator(1).execute("select i from " +
KEYSPACE + ".x WHERE id = 1", ConsistencyLevel.ALL);
Object[][] res2 = cluster.coordinator(2).execute("select i from " +
KEYSPACE + ".x WHERE id = 1", ConsistencyLevel.ALL);
assertArrayEquals(res1, res2);
}
}
{noformat}
Not able to get a failure, but perhaps I'm missing something. Either way, it
seems like a bad idea to allow altering UDTs once they are part of a primary
key...
> 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]
