thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Will Pierce <wi...@nuclei.com>
Subject Re: updating to longer ints
Date Thu, 14 Mar 2013 21:47:50 GMT
Definitely not an easy problem.  On the wire these will both encode as the
same field ID (1) and a type ID of 6 for the i16 or a type ID of 8 for the
i32.  Most (all?) thrift language bindings check to ensure the type ID for
a field matches the expected type ID for that particular field, silently
skipping past any field with mismatched type IDs.

George Chung's suggestion is the safest/cleanest approach.

I had exactly this same problem where I needed to expand from i32 to i64.
 It was a "flag day" cutover for me, since I had control of all the clients
and servers.  But I can see how you frequently can't upgrade all the client
code out in the wild.  (Or data files, if these are persisted.)

Rather than try to solve the broader problem of versioning, maybe we should
consider adding optional behavior to the decoder to permit
*type-promotion*when the field's on-wire type can be safely decoded
into the expected type?

Provided that the expected type can faithfully represent all the values of
the wire type, it seems like a way to follow the "TCP" pattern of being
permissive in what you receive, but strict in what you send.

In terms of thrift TTypes, we could allow a decoder to promote:
 bool > i08 > i16 > i32 > (double or i64)

This wouldn't solve every problem - like sending a response struct with an
i32 field to a client than expects i16.  No go there.  This would be only
useful in cases of having to read client input from a mixed bag of old and
new clients, where the server response struct doesn't need any wider
fields.  I'm not sure if that is your use-case...

Those using thrift for serialization to/from disk, I would imagine
type-promotion could save a lot of effort in re-encoding any old files that
use narrower numeric types than newer files...

Thoughts?

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message