Thanks for the quick reply -- I noticed this in the documentation
after searching for default instance:
"For embedded messages, the default value is always the "default
instance" or "prototype" of the message, which has none of its fields
set." So, does this mean that even the required fields will be set to
their default values in this prototype object? Or is there some other
algorithm for the values of the fields within the prototype/default
instance?
For broader context, I'm trying to figure out how to determine if an
optional field was actually set in the transmitted protocol buffer or
whether its default value was filled in automatically.
In reference to the example below, if the title field had been set to
"Field of Dreams" and then the user set it to an empty string "", I
would want to actually update the value in my data store to be the
empty string. However, if the user didn't change the title field at
all, I will still see an empty string in the title field when I try
and get at the field through the accessor. I'm looking for a way to
setup my protocol buffer format so I can distinguish between those two
cases.
Thanks again.
On Jun 4, 9:45 am, Jason Hsueh <jas...@google.com> wrote:
> No, protobuf accessors never return null. For message fields, you get the
> default instance of the message type.
>
>
>
> On Fri, Jun 4, 2010 at 9:32 AM, Jax <jax...@gmail.com> wrote:
>
> > This should be pretty straightforward, but I couldn't find it in any
> > of the documentation on default values.
>
> > A slight change from some example code in the google documentation:
>
> > message SearchResponse {
> > optional Result result = 1;
> > }
>
> > message Result {
> > required string url = 1;
> > optional string title = 2;
> > repeated string snippets = 3;
> > }
>
> > My question is, what is the default value for the Result in the above
> > code? Does it get set to null since (I presume) it will be compiled
> > into an object when the protocol buffer gets compiled into Java or C#?
> > Or do default values work differently for a nested message than for
> > base types?
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Protocol Buffers" group.
> > To post to this group, send email to proto...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > protobuf+unsubscr...@googlegroups.com<protobuf%2bunsubscr...@googlegroups.c
> > om>
> > .
> > For more options, visit this group at
> >http://groups.google.com/group/protobuf?hl=en.
--
You received this message because you are subscribed to the Google Groups
"Protocol Buffers" group.
To post to this group, send email to proto...@googlegroups.com.
To unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en.
