[
https://issues.apache.org/jira/browse/CASSANDRA-2056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018339#comment-13018339
]
Gary Dusbabek commented on CASSANDRA-2056:
------------------------------------------
Attached rebased v2. CliTest fails though, so not committing yet.
> Need a way of flattening schemas.
> ---------------------------------
>
> Key: CASSANDRA-2056
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2056
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Gary Dusbabek
> Assignee: Gary Dusbabek
> Fix For: 0.8
>
> Attachments: v2-0001-convert-MigrationManager-into-a-singleton.txt,
> v2-0002-bail-on-migrations-originating-from-newer-protocol-ver.txt,
> v2-0003-a-way-to-upgrade-schema-when-protocol-version-changes.txt
>
>
> For all of our trying not to, we still managed to screw this up. Schema
> updates currently contain a serialized RowMutation stored as a column value.
> When a node needs updated schema, it requests these values, deserializes them
> and applies them. As the serialization scheme for RowMutation changes over
> time (this is inevitable), those old migrations will become incompatible with
> newer implementations of the RowMutation deserializer. This means that when
> new nodes come online, they'll get migration messages that they have trouble
> deserializing. (Remember, we've only made the promise that we'll be
> backwards compatible for one version--see CASSANDRA-1015--even though we'd
> eventually have this problem without that guarantee.)
> What I propose is a cluster command to flatten the schema prior to upgrading.
> This would basically purge the old schema updates and replace them with a
> single serialized migration (serialized in the current protocol version).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
