[
https://issues.apache.org/jira/browse/THRIFT-2429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13962396#comment-13962396
]
Ben Sigelman commented on THRIFT-2429:
--------------------------------------
FYI, I am neither an official thrift maintainer nor a particularly experienced
thrift user, but [~jensg] made me aware of this thread (as I was cc'd on
something Golang-thrift related that bears some relevance) and I came over to
have a look.
With the caveats about my Thrift experience taken into consideration, I feel
obliged to at least throw in my two cents.
I think the proposed semantics are problematic. The good news is that the
arguments I would make have already been set forth :) I just wish that they
were taken to their natural conclusion.
Any distributed system of sufficient size/scale/maturity will have to contend
with different system components co-existing with divergent build timestamps /
software versions. There's also the case of data serialized to persistent
storage; it then needs to be properly readable/parseable later on by similarly
divergent software versions.
The case I care about here is when we're serializing an optional field that has
a default value. As I understand it (forgive me if I'm missing something),
after this change goes in, an optional field that's been *set* to its default
value *will not be serialized* over the wire.
For this to work properly, both reader and writer of the data in question must
have the same understanding of the default value. This is hugely problematic!
If the goal is to save bits in the wire protocol, it would be more reasonable
to ask the bit-saving programmer to handle this themselves and write custom
code. As-is, we're adding a gotcha for (IMO) questionable benefit.
As Randy put it earlier, "So while this proposal does put one more cow pie in
the changing default value meadow, the meadow had several cow pies already." --
let's remove some cowpies! My extreme proposal would be to remove default
values entirely... short of that, though, the only sane thing to do is to send
them over the wire. The whole point of things like Thrift is to make it easier
to build distributed systems with heterogeneous software versions... we should
not be adding features that make that *more* fragile rather than less fragile.
My two cents! Happy to elaborate if anyone cares. It seems like the battle is
mostly lost at this point, but figured there was no great harm in making the
case :)
Thanks for all of your hard work, Thrift maintainers!
> 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)
