Hi Jens, I did some research and here are changes that I think needs to be made to support this. I may be way off track so please let me know:
* Generate __*_ISSET_ID for all fields * Call set*IsSet(true) from set*() method for all fields * isSet* method should use __isset_bitfield to determine if a field is set or not * unset* method should clear the 'isset' bit for the field * We need a away to represent unspecified fields in protocols. I can think of two solutions: ** Use a specials character like unicode null character ** Marshal __isset_bitfield alongside other fields and update org.apache.thrift.scheme.IScheme.read methods to unmarshal it I'm not sure if this mailing list is the right place for this discussion so please let me know if I should move this to jira or developers mailing list. Thanks, -Sid On Tue, Jan 1, 2013 at 2:02 AM, Jens Geyer <[email protected]> wrote: > Hi Sid, > > there has been some discussion around this topic and there are also some > JIRA tickets that deal with this matter. I don't have them at hand right > now, but searching the mail archives and having a look at > https://issues.apache.org/jira/browse/THRIFT-1469 could be a good start. > > The intended way to indicate presence of an optional field are the __isset > flags. These flags are usually generated for optional fields only. > > Have fun, > JensG > > > > -----Ursprüngliche Nachricht----- From: Sid Golestane > Sent: Tuesday, January 1, 2013 2:28 AM > To: [email protected] > Subject: Distinguish null vs unspecified value in java > > > Hi, > > Per section 5.2 of thrift white paper "When an expected field is not > found, there must be > some way to signal to the developer that it was not present". > > Considering the above, I was wondering if there is anyway to > distinguish null vs an unspecified value in java? As far as I can tell > current implementation treats both as null which mean we can't add any > new nillable field without breaking forward compatibility. > > Thanks, > -Sid
