thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randy Abernethy ...@apache.org>
Subject Re: Is the Thrift serialization compatible both directions?
Date Fri, 19 Jan 2018 02:18:22 GMT
Taking this apart:

- Any new fields that you add should be optional.
I disagree, default requiredness with a default value works fine as well
(and is my preference if you are not interested in optimizing the field
away in procs that know about it). On the server side,if the default field
is there great, if not the default value is used. On the client side if the
field is known it is sent if not it is not.

- This means that any messages serialized by code using your "old" message
format can be parsed by your new generated code, as they won’t be missing
any required elements.
True and true with default requiredness as well.

- Similarly, messages created by your new code can be parsed by your old
code: old binaries simply ignore the new field when parsing.
True and true with default requiredness as well.

- However, the unknown fields are not discarded, and if the message is
later serialized, the unknown fields are serialized along with it — so if
the message is passed on to new code, the new fields are still available.
This is inaccurate. If you use Thrift "normally", when you deserialize, the
struct (message) will only contain the fields you know (in any
requiredness).

--Randy

On Thu, Jan 18, 2018 at 7:59 AM, Jean Rodier <
Jean.Rodier@tatacommunications.com> wrote:

> Hi,
>
> Is this statement true, especially the last part?
>
> Any new fields that you add should be optional. This means that any
> messages serialized by code using your "old" message format can be parsed
> by your new generated code, as they won’t be missing any required elements.
> Similarly, messages created by your new code can be parsed by your old
> code: old binaries simply ignore the new field when parsing. However, the
> unknown fields are not discarded, and if the message is later serialized,
> the unknown fields are serialized along with it — so if the message is
> passed on to new code, the new fields are still available.
>
> Jean
>

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