Protobuf Required Fields

One limitation of protobuf 3 schemas, is they doen't allow required fields. That makes it easier to remove the field in a later version in a backwards compatible way, but sometimes fields really are required, and the message doesn't make any sense without them. Ideally, IMO, if the message is missing those fields, it would fail to parse successfully. But with protobuf, you instead get a default value, which could potentially cause subtle bugs.

Protocol Buffers are flexible because they support 'optional' fields. So we can change the structure of Protocol Buffer without breaking the system.

"The solution is as follows:Make all fields in a message required. This makes messages product types."Except it also breaks backwards compatibility, one of the most powerful and sought-after features of protobufs.

I can't follow that argument, as it seems to apply just as much to wanting to change the type of a field, the name of a field or just making changes in general. Maybe I deal with relational databases too much, but I really miss being able to declare fields required and provide default values, because now instead I have to document, trust others will read the documentation, and provide explicit error handling for when constraints that used to be validated client side or server side by protob

With Protobuf this is a conscious decision to avoid back-compat issues. I'm not sure if I like it.

Didn't read article fully, but - since it's protocall buffer definitions, what if these fields are there for backward compatibility?

Compare with the usual rules for protobuf evolution:All fields are optional. This is because fields have a lifecycle. Your code might be reading data generated by some other code written before the field was defined, or generated by some other code written after the field became obsolete.With protobufs, you can never reuse a field number. However, you can remove a field (keeping its number reserved), which effectively means ignoring it in new applications. It's neither read nor writte

I agree. Preserving unknowns fortunately was recognized as mistake, and fixed in some more recent version, and presence can be worked around: it is still preserved for message types, so you only need to wrap your primitives into objects[1], Java style.[1] - https://developers.google.com/protocol-buffers/docs/referenc...

Why is the lack of a schema indicator the biggest flaw of protobuf?

If you don't currently have protobuf definitions, you can just not use required fields in any new ones you write, like the quoted passage suggests.