This is definitely not true, at least in ruby and java. I would be surprised if any of the other libraries supported this.
On Tue, Apr 17, 2012 at 3:08 PM, Nevo Hed <[email protected]> wrote: > Hi All > > In The Missing Guide > (http://diwakergupta.github.com/thrift-missing-guide/)< > http://diwakergupta.github.com/thrift-missing-guide/> > , > Under "Best Practices/Versioning/Compatibility", at the end of 2nd bullet > it states: > > > However, the unknown fields are not discarded, and if the message is > later > > serialized, the unknown fields are serialized along with it — so* if the > > message is passed on to new code, the new fields are still available*. > > > This is really good theory, but is this really true? If so, is it true for > all languages? > > For one I don't see how this would be possible if I look at the generated > C++ code. For y type "MyType", the generated MyType::write() > only references known fields from the thrift file used at compile time. I > also ran a ruby test that showed similar results (write file with old > version, read with new, add new optional field, write file, confirm by > reread, then read in old version, rewrite file, and new fields is gone). > > As there is only storage for the fields known at compile time, I can only > see this as plausible for languages offering > reflection<http://en.wikipedia.org/wiki/Reflection_(computer_programming)> > . > > Of course, if one maintains the bitstream (for example by keeping the > original serialized buffer, say in a TMemoryBuffer), then it can be > transmitted along to another system element, but the current element would > only be able to act as a message router, and not actually augment the > message. > > Am I missing anything? > > Thanks > > -Nevo >
