[
https://issues.apache.org/jira/browse/THRIFT-2429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13958335#comment-13958335
]
Randy Abernethy commented on THRIFT-2429:
-----------------------------------------
Hey Jens,
Thanks for looking this over. The possibility of out of sync defaults is not
optimal to be sure. Things can get interesting when the reader and writer have
different IDL versions involving default values. For example, presently if we
have three versions of an IDL something like this:
* 1: //1: i32 x #retired
* 2: 1: i32 x = 5
* 3: 1: i32 x = 10
If a client using version 1 calls a server using version 2, that server assumes
x of 5. If the same client calls another server offering the same interface but
version 3, that server will set x to 10. This could produce unexpected results.
This could happen in a staged roll out or in settings where multiple
organizations are collaborating through the IDL with different release
schedules and versioning priorities. This is just one example among many where
IDL evolution with changing default values can pose a problem. The fact that
this is a concern today, leads me to suggest that changing default values in
IDL can be harmful.
I think the proposed change is unlikely to break many (if any) existing
interfaces, because defining a field as optional with a default value today
means the optional modifier is almost always ignored. The optional modifier is
also essentially a transmission optimization, allowing us to omit unnecessary
data from the stream. I like the fact that in this proposal optional functions
in the traditional way (as an optimization), making the transmission of the
default value optional.
So while this proposal does put one more cow pie in the changing default value
meadow, the meadow had several cow pies already. In essence any use of defaults
requires a hearty warning to ensure that your defaults are in synch across
versions or that your interface semantics can cope with different default
values in different subsystems.
-Randy
> 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)
