pros and cons to upgrade protobuf v3
1,698 views
Skip to first unread message
hce h
Jul 14, 2017, 7:33:35 AM7/14/17
to Protocol Buffers
Hi,
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,
-j
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,
-j
Josh Humphries
Jul 14, 2017, 9:45:18 AM7/14/17
to hce h, Protocol Buffers
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 syntax.
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 syntax.
--
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 protobuf+unsubscribe@googlegroups.com.
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.
hce h
Jul 14, 2017, 9:29:46 PM7/14/17
to Protocol Buffers, jupit...@gmail.com
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?
Thank you.
Kind regards,
- j
To unsubscribe from this group and stop receiving emails from it, send an email to protobuf+u...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages