You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@thrift.apache.org by "Eric Anderson (JIRA)" <ji...@apache.org> on 2009/04/08 23:46:13 UTC

[jira] Commented: (THRIFT-236) Structs should be serialized in a consistent order

    [ https://issues.apache.org/jira/browse/THRIFT-236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12697227#action_12697227 ] 

Eric Anderson commented on THRIFT-236:
--------------------------------------

There is one advantage to recording the order of fields in the IDL.  If you have constructors for objects that don't name their parameters, then it's useful to be able to keep the IDL order in "human-natural" order, yet let the tag numbers change as needed to support schema evolution.  Consider the following evolution:

struct circle { required 1: i32 x; required 2: i32 y; required 3: i32 radius; }

— V2: (assuming a series of intermediate ones with the necessary optionals)

struct point { required 1: i32 x; required 2: i32 y; }

struct circle { required 4: point center; required 3: i32 radius; }

The problem is that the latter circle would be initialized as circle(radius, center), which seems inverted to me from the "expected" order for defining such an object. However, I can't reuse the 1 and 2 tags because they are obsolete (as I understand the thrift migration of structure tag rules)

> Structs should be serialized in a consistent order
> --------------------------------------------------
>
>                 Key: THRIFT-236
>                 URL: https://issues.apache.org/jira/browse/THRIFT-236
>             Project: Thrift
>          Issue Type: Improvement
>            Reporter: Bryan Duxbury
>            Assignee: Alexander Shigin
>             Fix For: 0.1
>
>         Attachments: sort-fields.diff, thrift-236.patch, thrift-consistent-order-v2.patch, thrift-consistent-order-v3.patch, thrift-consistent-order.patch
>
>
> As it stands right now, Ruby generated structs will be serialized in arbitrary order (due to storage of metadata in a hash). This leads to different binary encoding for the same struct values. Ideally, it should be the same for any two serializations of equivalent structs, and between languages if possible. 
> The two approaches that seem to make the most sense are in lowest-to-highest field id order, and in IDL-defined order. What do people think of this idea, and which approach would be preferred?

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