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.rod...@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 >
