[ https://issues.apache.org/jira/browse/CASSANDRA-2056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13017664#comment-13017664 ]
Jonathan Ellis commented on CASSANDRA-2056: ------------------------------------------- +1 (can you fix spelling of "reconstituded" while you're at it? :) > 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: v1-0001-convert-MigrationManager-into-a-singleton.txt, > v1-0002-bail-on-migrations-originating-from-newer-protocol-ver.txt, > v1-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