[
https://issues.apache.org/jira/browse/THRIFT-2429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13951432#comment-13951432
]
Randy Abernethy commented on THRIFT-2429:
-----------------------------------------
Hey Chris,
More likely a bad explanation, let me take another swing:
There are two relevant scenarios involving default values with Thrift today and
we are talking about adding a third scenario. In the scenarios below assume the
client does not set any values explicitly.
*1 - The default value is assigned by the client.*
If the client and server are using the v1 IDL below the client will always
transmit x as 5 and the server will use 5.
{code:title=testv1.thrift|borderStyle=solid}
struct data {
1: i32 x = 5
}
service test {
void func(1: data dx)
}
{code}
*2 - The default value is assigned by the server.*
This is how defaults work if the client doesn't know about the field but the
server does. Assume the client knows the v1 IDL above, ... but the server knows
the v2 IDL below. The client never sends y and the server side always
initializes y to a value of 3.5, so the server always sees 3.5.
{code:title=testv2.thrift|borderStyle=solid}
struct data {
1: i32 x = 5
2: double y = 3.5
}
service test {
void func(1: data dx)
}
{code}
*3 The default may be set by the client or the server.*
This is the semantic we are interested in adding. I suggest we assign this
behavior to the combination of optional and default as in the v3 IDL below.
Presently the v3 IDL will always set x to 5 and it will therefore always be
sent. In essence the optional keyword has no effect on a field with a default
value (in most languages).
{code:title=testv3.thrift|borderStyle=solid}
struct data {
1: optional i32 x = 5
}
service test {
void func(1: data dx)
}
{code}
I propose we redefine (or perhaps clearly define for the first time) the
meaning of an optional field with a default value to mean:
- When serializing, the value is never serialized unless explicitly set
- When deserializing, if the value is found it is used, otherwise it is set to
the default
I like this approach because it:
1. Keeps the interface in the IDL where it belongs (changing a system's
interface with compiler switches strikes me as problematic on many levels)
2. Lets you mix the old and new semantics within a single compilation unit (not
so with a compiler switch)
3. Gives us a feature desired for some time (don't force us to transmit
defaults when we don't want to)
4. Gives the combination of optional and default a clear cross language meaning
where previously things were a little muddy.
This will only work with stucts presently because function parameters can not
be optional, though I suppose we could address that if need be given that
function parameters are implemented as a struct under the covers. I haven't
been able to come up with any other down sides (however, I'm sure the list will
inform me if I error!).
Thoughts?
-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: 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)
