Thanks Josh, we don't use default values, we don't use extensions and we
don't use accessor methods. All our messages (C++) are using very simple
native fields and embedded without messages or messages imported from other
packages. You comments encouraged me even more to upgrade the v3.
Correct me if I am wrong, but I think in v3, if an error message returns
without filling all fields, the libprotobuf.so will not throw an exception,
is that correct?
On Friday, July 14, 2017 at 11:45:18 PM UTC+10, Josh Humphries wrote:
> You can use the latest version but still use a corpus files
> syntax="proto2" files.
> Marking required fields as optional is not the only difference (and, in
> proto2, that is not a particularly safe operation -- you must be certain
> you've updated *all* readers of those messages with the new definition
> *before* any writers actually choose to omit those fields).
> If you are using default values or extensions, your migration to proto3
> syntax will be trickier as neither is supported. Also, proto3 doesn't
> provide accessor methods to detect whether a field is present or not (it is
> implicitly absent if it has the "zero value" for its type).
> Luckily, you can start using the latest protoc and then slowly migrate.
> The proto compiler does allow a mix of proto2 and proto3 syntax files --
> proto3 files can import proto2 files (though I can't recall if the other
> direction is allowed -- I think it is though, to support custom options
> that might reference messages defined in proto3). One path for migration is
> to start using proto3 for all new files. This gives you optionality as far
> as how and when to convert the rest.
> If you don't use default values or extensions, converting a proto2 syntax
> file to proto3 is quite simple. But, depending on the language you use, it
> will impact application code that interacts with the generated code.
> (Proto3 files do not generate pointers in the structs for scalar fields,
> for example.) Also note that custom options *are* still supported, but
> since they rely on extensions they must be defined in a file with proto2
> *Josh Humphries*
>> I had a debate with my colleagues regarding to upgrade protobuf v3
>> because I'd like to use MessageToJsonString and JsonStringToMessage for GUI
>> development of web application and mobile app, but my colleagues are not
>> convinced, they argued GO can do it very easily and they are worrying about
>> to break the systems down as our protobuf v2 codes are used crossing many
>> systems. I always think it is logical to use the latest version of the
>> software which should fix bugs and add more features, in addition to that,
>> I don't like v2 required field and many of our codes have problems when the
>> process returns an error message before reaching the destination, the error
>> message was not able to fill in all required fields caused libprotobufbuf
>> broken the system daemon, I have recently changed many required fields to
>> optional, I thought protobuf v3 should be more stable than the v2, but I am
>> also new to protobuf v3, appreciate your comments.
>> Thank you.
>> Kind regards,
>> 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
>> To post to this group, send email to prot...@googlegroups.com
>> 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 post to this group, send email to firstname.lastname@example.org.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.