cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (Commented) (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-4017) Unify migrations
Date Thu, 15 Mar 2012 13:21:38 GMT


Sylvain Lebresne commented on CASSANDRA-4017:

I've put some initial patch at

As described above, the main idea is to unify code between what happens on the initial node
applying the migration and the rest of the nodes. With this patch, when a schema change has
to happen, we generate the RowMutation corresponding and send it to all nodes (including the
localhost) and all the node use that to figure out what changed and how to update in-memory
structures. The patch removes the Migration classes (that weren't doing much anyway) and moves
a bit a code around to make it easier to follow a migration path.

Sadly, this ended up posing problem with the unit tests. More precisely, SchemaLoader was
not using the migration path, but only loading the schema in-memory. Because the patch removes
the local special case, this was breaking DefsTest. The solution was to make SchemaLoader
use actual migrations (to get stuffs written to disk). But now that means that SchemaLoader
needs to be merged with CleanupHelper (otherwise, since the cleanup was happening with the
schema loading, the loading was conflicting with the schema of the previous test).

When that's fixed (which the patch does), MoveTest still broke with a ClassCastException between
BytesToken and BigIntegerToken. The reason is that MoveTest use {{ss.setPartitionerUnsafe}}
to set the RandomPartitioner. But it does that *after* the schema has been loaded. But now
the schema happens to trigger flushing of system tables. Those are flushed with the order
preserving partitioner and later conflict with the sstable created after the partitioner change.
I'm not sure what the best fix is for this and so the patch doesn't fix that failure. Maybe
we could just make MoveTest keep the test partitioner.  But I suppose the intention was to
test the random partitioner, so ....

> Unify migrations
> ----------------
>                 Key: CASSANDRA-4017
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>    Affects Versions: 1.1.0
>            Reporter: Jonathan Ellis
>            Assignee: Sylvain Lebresne
>             Fix For: 1.1.0
> Now that we can send a schema as a RowMutation, there's no need to keep separate add/drop/update
migration classes around.  Let's just send the schema to our counterparts and let them figure
out what changed.  Currently we have "figure out what changed" code to both generate migrations
on the sender, and for application on the target, which adds complexity.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


View raw message