Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Wed, 9 Feb 2011 16:19:57 +0000 (UTC)
From: "Gary Dusbabek (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: 
 <1788169119.5333.1297268397500.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: <30172297.202611295995786095.JavaMail.jira@thor>
Subject: [jira] Updated: (CASSANDRA-2056) Need a way of flattening schemas.
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/CASSANDRA-2056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Gary Dusbabek updated CASSANDRA-2056:
-------------------------------------

    Attachment: v1-0003-a-way-to-upgrade-schema-when-protocol-version-changes.txt
                v1-0002-bail-on-migrations-originating-from-newer-protocol-ver.txt
                v1-0001-convert-MigrationManager-into-a-singleton.txt

> 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