On Tue, May 17, 2016 at 7:53 PM, Teddy Zhang <[email protected]> wrote:
> I'm really not happy to see that proto3 removed the ability in generate
> code for check whether a field exits or not.
>
> For a message like this:
> message Test1 {
> required int32 a = 1;
> }
> If field a is present, the encoded message will have field with id 1 and
> its value. If the field is not set, the encoded message will not have field
> id 1.
> In proto2 generated code, it provides a has method to check whether the
> field exists or not.
> In proto3, this is no such thing. During deserialization, if the field is
> not exists, default value is set. So you can't tell whether the field does
> not exist or have a default value. That doesn't match the underline
> encoding anymore.
>
> This is a breaking change and will portentially impact a lot of people.
> Basically we're losing nullable support.
> For our project, we heavily depends on that. There are workarounds (add
> a Boolean field) but it is ugly. I think that will stop us from moving from
> proto2 to proto3 (may need find alternatives).
>
There are two workarounds to get back the field presence info in proto3.
1. Use a wrapper message, such as google.protobuf.Int32Value
<https://github.com/google/protobuf/blob/master/src/google/protobuf/wrappers.proto#L84>.
In proto3, message fields still have has-bits.
2. Use an oneof. For example:
message Test1 {
oneof a_oneof {
int32 a = 1;
}
}
then you can check test.getAOneofCase().
> Can we add the functionality back?
>
It's very unlikely to happen as proto3 features are already finalized and
implemented in many languages.
>
>
> On Saturday, March 26, 2016 at 11:47:08 AM UTC-7, Ilia Mirkin wrote:
>
>> Use proto2, which has the has_* checks per field. (Using get_* you
>> still get the default value, of course.) It's extremely unfortunate
>> that this functionality was removed in proto3, I see that making
>> proto3 unattractive for all but the simplest uses of protos. I know in
>> almost every protobuf use-case I've had, the presence accessors were
>> imperative to proper operation.
>>
>> On Sat, Mar 26, 2016 at 2:43 PM, Yoav H <[email protected]> wrote:
>> > Hi,
>> >
>> > I wanted ask regarding the decision to populate fields with default
>> values,
>> > even if they do not appear in the encoded message.
>> > If I want to send a "patch" message, where I want to update just the
>> > provided fields, how can I do that with protobuf (without adding
>> IsXXXSet
>> > for every field)?
>> >
>> > Why not add another type, representing a default value?
>> > So the schematics would be, if the field is missing, it is null, and if
>> the
>> > field exists, but with this "missing value" type, it will get the
>> default
>> > value?
>> >
>> > Thanks,
>> > Yoav.
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> Groups
>> > "Protocol Buffers" group.
>> > To unsubscribe from this group and stop receiving emails from it, send
>> an
>> > email to [email protected].
>> > To post to this group, send email to [email protected].
>> > Visit this group at https://groups.google.com/group/protobuf.
>> > For more options, visit https://groups.google.com/d/optout.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Protocol Buffers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To post to this group, send email to [email protected].
> Visit this group at https://groups.google.com/group/protobuf.
> For more options, visit https://groups.google.com/d/optout.
>
--
You received this message because you are subscribed to the Google Groups
"Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.
