[ https://issues.apache.org/jira/browse/THRIFT-2429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13966737#comment-13966737 ]
Ben Sigelman commented on THRIFT-2429: -------------------------------------- Thanks, Randy. I did a little bit of research about this, and came away with the sense that {{required}} is not equivalent to {{optional}} in PB. E.g., this passage: {quote} Required Is Forever: You should be very careful about marking fields as required. If at some point you wish to stop writing or sending a required field, it will be problematic to change the field to an optional field — old readers will consider messages without this field to be incomplete and may reject or drop them unintentionally. You should consider writing application-specific custom validation routines for your buffers instead. Some have come the conclusion that using required does more harm than good; they prefer to use only optional. However, this view is not universal. {quote} (That's taken from [this document|http://diwakergupta.github.io/thrift-missing-guide/#_defining_structs]) I tried and failed to find the doc that precisely described the semantics of {{required}} underneath thrift.apache.org... I'd be happy to RTFM if you help find it for me. If {{required}} in thrift is indeed equivalent to {{optional}} in PB, then I guess I'm less concerned about this proposal but considerably more confused about Thrift :) > 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)