[
https://issues.apache.org/jira/browse/THRIFT-1528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13865047#comment-13865047
]
Nate Rosenblum edited comment on THRIFT-1528 at 1/8/14 4:17 AM:
----------------------------------------------------------------
>From my perspective, the downside of _not_ serializing optional-defaulted is
>that it ties the runtime state of the protocol to the IDL file itself. I
>certainly see the inefficiencies inherent in serializing these fields if one
>makes heavy use of them & doesn't change the default values. Could I go back
>in time, I would argue against allowing this functionality at all; it seems
>less error prone to encode this defaulting directly in application logic,
>rather than to make it part of the protocol specification. I suppose one could
>argue either way, according to preference.
The problem that I originally ran into was binary compatibility of protocol
messages, specifically for computing signatures over the serialized data. I
think it's perfectly reasonable to make the serializing behavior configurable,
as long as binary compatibility remains an option.
was (Author: nater):
>From my perspective, the downside of _not) serializing optional-defaulted is
>that it ties the runtime state of the protocol to the IDL file itself. I
>certainly see the inefficiencies inherent in serializing these fields if one
>makes heavy use of them & doesn't change the default values. Could I go back
>in time, I would argue against allowing this functionality at all; it seems
>less error prone to encode this defaulting directly in application logic,
>rather than to make it part of the protocol specification. I suppose one could
>argue either way, according to preference.
The problem that I originally ran into was binary compatibility of protocol
messages, specifically for computing signatures over the serialized data. I
think it's perfectly reasonable to make the serializing behavior configurable,
as long as binary compatibility remains an option.
> Inconsistency in optional fields between Java/C# and python
> -----------------------------------------------------------
>
> Key: THRIFT-1528
> URL: https://issues.apache.org/jira/browse/THRIFT-1528
> Project: Thrift
> Issue Type: Bug
> Components: Python - Compiler
> Affects Versions: 0.8
> Reporter: Stefan Gmeiner
> Fix For: 1.0
>
>
> If a struct contains optional fields with default values the generated python
> code serialize differently than Java or C# code.
> In Java or C# optional fields are only serialized if a field was set by the
> client. If not the field is omited during serialization. This is possible
> because C#/Java maintains for each field a 'isset'-boolean which records if a
> field was set or not.
> However the generated python code does not have such a 'isset'-structure. It
> writes every field which is not equal None. As the constructor initialize the
> optional fields with their default value, these fields are written whether
> they are set or not.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
