How to check empty message object

[s_mitra]

Hi,

I have doing some coding related to protobuf where server and client will exchange some info via protobuf.

In the response object I have multiple optional message objects.
How to check which all object is empty and which is not ??

[Alfred Kwan]

It depends on what protobuf version you are using. There will be a had_foo() for each optional field if you are using protobuf version 2.xx (see C++ code reference). You are out of luck if you are using V3.0 because you will have to create your own boolean fields if you need to track whether the optional is populated or not.

[Nikolay Ananenko]

you will have to create your own boolean fields if you need to track whether the optional is populated or not.

 

Other approach is to use repeated with <=1 element instead of optional. Then had_foo()  analogue will be (get_foo_size() != 0), presence flag and the data will be kept within the same field and a bonus - optional is compatible with repeated,  so this should not break format compatibility.

[V.B.]

Open question to everyone. I'm curious.
In all of your use-cases with protobuf, how often do you find yourself using  has_foo() (a.k.a. "hazzers") for primitive fields? We use them almost everywhere because, for example, it is a very useful way of error-checking requests on the server sent from our client code on mobile devices. Maybe we're just outliers.

Google's stated reason for getting rid of presence logic is below (bolding by me):

It's believed that most users don't use the field presence logic much and for those who need this feature adding a bool field is an easy workaround.

... It would definitely not be an easy workaround for us given how much we rely on presence logic. Are we in the minority?

[Alfred Kwan]

There are more than just the rationale of "most users don't use the field presence logic much".

If I understand it correctly, Google wants to make proto3 available to other languages  (e.g. Ruby) where there is no concept of default values, meanwhile 'has_foo()' relies on the default value, which means everything is optional now and these "hazzers" logics have to go away.

[Robert Edmonds]

Alfred Kwan wrote:
> There are more than just the rationale of "most users don't use the field
> presence logic much".
> If I understand it correctly, Google wants to make proto3 available to
> other languages (e.g. Ruby) where there is no concept of default values,
> meanwhile 'has_foo()' relies on the default value, which means everything
> is optional now

If I understand the removal of field presence logic, this means there is
no way to tell the difference between a zero value and the field not
being present. E.g., if I have a field like (in proto2 syntax, from a
real .proto file):

// This is the number of seconds since the UNIX epoch.
optional uint64 response_time_sec = 12;

Without field presence logic, I can't tell the difference between the
field being unset, and the zero value (i.e., the value corresponding to
Thu Jan 1 00:00:00 UTC 1970, in this case).

I don't see how default values enters into it.

> and these "hazzers" logics have to go away.

Google says, "we will continue to support proto2 for a long time."

--
Robert Edmonds

[V.B.]

I don't see how default values enters into it.

Same here. I don't see it either.

[V.B.]

 

> and these "hazzers" logics have to go away.

Google says, "we will continue to support proto2 for a long time."

 

True, but it also means that if we ever want to use proto3 features (which we do), then we have to trade away presence logic for primitive fields. This is an unfortunate decision to have to make.

[Alfred Kwan]

I meant the hazzers have to go away for proto3 ;-)

We have been evaluating proto2 vs proto3 and I have posted a few questions/issue about the 'has_foo()' logic, their answers gave me an impression of this is related to the default value. Btw the alpha-1 release notes says:

1. Removal of field presence logic for primitive value fields, removal of required fields, and removal of default values. This makes proto3 significantly easier to implement with open struct representations, as in languages like Android Java, Objective C, or Go.

[Simon Brandhof]

What are the side-effects to define wrapper messages as a workaround ? 

message Foo {

  Int32 bar = 1;

}

message Int32 {

  int32 value = 1;

}

In Java it allows to have Foo.hasBar() and Foo.getBar().getValue().

[Ilia Mirkin]

Sub-message involves a lot more encoding overhead, both cpu time
(creating objects) as well as larger data encoding (extra tag + length
get encoded -- an extra 2 bytes).