[jira] [Comment Edited] (THRIFT-1528) Inconsistency in optional fields between Java/C# and python

["Nate Rosenblum (JIRA)" <ji...@apache.org>]

    [ 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)