You mean in Java, right? Are you using the "beans" option to the generator?
Background: isset was originally only meant to be used after reading. It would indicate whether or not the sending side knew of the field, not whether it chose to send it or not. Later, we received a patch for C++ that enabled you declare a field as "optional" meaning that it would never be serialized unless you explicitly set the its isset to true. Eventually, that was ported to Java. Finally, Bryan had a patch that eliminated the explicit isset bit in a lot of cases and instead used null as a placeholder for an unset field. I don't remember the exact semantics of this patch, though, and there are four main cases: nullable in beans mode, nullable in normal mode, primitive in beans mode, primitive in normal mode. --David Mathias Herberts wrote: > Hi, > > the way the write is currently implemented, fields are serialized > regardless of their setting (i.e. some are compared to null instead of > checking the associated isSet method, some are systematically > serialized such as integers). This means that the semantics of the > isSetXXX methods are different before and after a > serialization/deserialization run. > > It seems to me that the return values of isSetXXX should be preserved, > or is there a reason not to? > > Mathias.
