[
https://issues.apache.org/jira/browse/THRIFT-2429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13950816#comment-13950816
]
Randy Abernethy commented on THRIFT-2429:
-----------------------------------------
Hi Chris,
Default parameters (particularly when combined with the optional flag) have a
lot of (poorly documented) subtlety about them. We really need a single clear
concise write up on both optional and default functionality at the abstract
level to clarify this stuff for everyone.
The problem with not passing the default value is that the server may have a
different opinion of what the default value is. Imagine a scenario where an IDL
file describes a default value of 5 for parameter x.
service test {
void func(1: i32 x = 5)
}
Both client and server are built with this version and all is well. Then new
requirements cause the IDL to be revised to:
service test {
void func(1: i32 x = 6, 2: double y=3.5)
}
The Apache Thrift interface evolution features make this a non-breaking change
for all combinations of clients and servers.
1. Old Client ==> New Server, the default for y is applied on the server side
to make up for the old client's inability to pass y
2. Old Client ==> Old Server, x is passed as always
3. New Client ==> Old Server, old server ignores parameters it does not
recognize, y
4. New Client ==> New Server, x and y are passed as expected
Not passing the default causes problems in scenario 2. The new server thinks
the default for x is 6 but the old client thinks it is 5, this could cause
undefined behavior in some interfaces. If the old client passes the value then
we don't have a problem.
So why have a default you ask? Consider scenario 2 again. In this case the old
client does not pass a value for y. If the server has no default a call from an
old client would have to be rejected. Default values also allow you to delete
parameters from the interface without violating the conditions of older
implementations.
When you begin to have large scale distribution of Thrift interfaces with many
diverse customers depending on their consistent behavior, these interface
evolution features are critical benefits. So while transmitting default values
is not optimal from a serialization and network bandwidth stand point, the
trade off is worthwhile in large scale systems.
-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
> Labels: thrift
>
> 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)
