You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Stu Hood (JIRA)" <ji...@apache.org> on 2010/11/18 03:09:15 UTC

[jira] Issue Comment Edited: (CASSANDRA-1015) Internal Messaging should be backwards compatible

    [ https://issues.apache.org/jira/browse/CASSANDRA-1015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12933289#action_12933289 ] 

Stu Hood edited comment on CASSANDRA-1015 at 11/17/10 9:08 PM:
---------------------------------------------------------------

> How will avro handle the situation where we've been sending a field as a string, but we decide to convert it to an enum and
> send it as an int in the future for compactness?
Avro and Thrift have a similar approach in this situation: changing the name of the field when you change its type. If a record has the old field, programmatically perform the necessary conversion as a validation step: once the object is valid, use it as usual. Once older schemas containing the field are deprecated, you can remove the vestigial field from the current schema.

For Avro in particular, the version field would decide which Avro schema to assume the writer (remote node) of the message used: the reader (local node) would always use the current schema. The validation step would then use the writer's schema version to decide which vestigial fields to decode.

The key benefit of Avro/Thrift here are that they separate (de)serialization from version conversion: ICompactSerializer as it exists mashes backwards compatibility into if statements that decide what fields to look for on the wire.

      was (Author: stuhood):
    > How will avro handle the situation where we've been sending a field as a string, but we decide to convert it to an enum and
> send it as an int in the future for compactness?
Avro and Thrift have a similar approach in this situation: changing the name of the field when you change it's type. If a record has the old field, programmatically perform the necessary conversion as a validation step: once the object is valid, use it as usual. Once older schemas containing the field are deprecated, you can remove the vestigial field from the current schema.

For Avro in particular, the version field would decide which Avro schema to assume the writer (remote node) of the message used: the reader (local node) would always use the current schema. The validation step would then use the writer's schema version to decide which vestigial fields to decode.

The key benefit of Avro/Thrift here are that they separate (de)serialization from version conversion: ICompactSerializer as it exists mashes backwards compatibility into if statements that decide what fields to look for on the wire.
  
> Internal Messaging should be backwards compatible
> -------------------------------------------------
>
>                 Key: CASSANDRA-1015
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-1015
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>            Reporter: Ryan King
>            Assignee: Gary Dusbabek
>            Priority: Critical
>             Fix For: 0.8
>
>
> Currently, incompatible changes in the node-to-node communication prevent rolling restarts of clusters.
> In order to fix this we should:
> 1) use a framework that makes doing compatible changes easy
> 2) have a policy of only making compatible changes between versions n and n+1*
> * Running multiple versions should only be supported for small periods of time. Running clusters of mixed version is not needed here.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.