[jira] [Commented] (CASSANDRA-2056) Need a way of flattening schemas.
[ https://issues.apache.org/jira/browse/CASSANDRA-2056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13170478#comment-13170478 ] Gary Dusbabek commented on CASSANDRA-2056: -- bq. This is obsolete post-CASSANDRA-1391 This ticket is orthogonal to 1391. The purpose for flattening schemas is to make is so we do not have to maintain compatibility for the migration serializers indefinitely (for the purpose of bootstrapping a new node). 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 Priority: Minor 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. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2056) Need a way of flattening schemas.
[ https://issues.apache.org/jira/browse/CASSANDRA-2056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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
[jira] [Commented] (CASSANDRA-2056) Need a way of flattening schemas.
[ https://issues.apache.org/jira/browse/CASSANDRA-2056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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
