[
https://issues.apache.org/jira/browse/THRIFT-2429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13970087#comment-13970087
]
Aleksey Pesternikov commented on THRIFT-2429:
---------------------------------------------
Ben,
I still believe that protobuf got this thing right:
https://developers.google.com/protocol-buffers/docs/proto#updating
Changing a default value is generally OK, as long as you remember that *default
values are never sent over the wire*. Thus, if a program receives a message in
which a particular field isn't set, the program will see the default value as
it was defined in that program's version of the protocol. It will NOT see the
default value that was defined in the sender's code.
So it is not golang implementation specific.
Having defaults serialized is a little bit overkill just for convenience of
seeing the default value compiled in the sender. It does not solve consistency
problem anyway, because in a real situation, as you have mentioned, software
deployment is not instant and sender could be deployed gradually so receiver
would see different values for the same field.
my 10c: no defaults for optional fields on wire.
> Provide option to not write default values, rely on receiver default
> construction instead
> -----------------------------------------------------------------------------------------
>
> Key: THRIFT-2429
> URL: https://issues.apache.org/jira/browse/THRIFT-2429
> Project: Thrift
> Issue Type: Improvement
> Components: C++ - Compiler
> Affects Versions: 0.9.1
> Reporter: Chris Stylianou
> Assignee: Randy Abernethy
> Labels: default, optional, required
>
> Would there be any objections to a patch that does not write default values
> (essentially the same logic as the optional attributes). This obviously
> relies on the receiving application using the same IDL version to ensure the
> defaults used on object construction match the senders.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
