IsSet information lost on serialization/deserialization

[Mathias Herberts <ma...@gmail.com>]

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.

Re: IsSet information lost on serialization/deserialization

[David Reiss <dr...@facebook.com>]

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.