Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

why messge type remove 'required,optional'? #2497

Closed
bullyork opened this issue Dec 14, 2016 · 4 comments
Closed

why messge type remove 'required,optional'? #2497

bullyork opened this issue Dec 14, 2016 · 4 comments

Comments

@bullyork
Copy link

The 'required,optional' types are useful for client to know which param is required and which is optional.

@seishun
Copy link
Contributor

seishun commented Dec 15, 2016

You mean in proto3? Because proto3 doesn't have a notion of presence anymore, so optional and required doesn't make sense.

@xfxyjwf
Copy link
Contributor

xfxyjwf commented Dec 15, 2016

We dropped required fields in proto3 because required fields are generally considered harmful and violating protobuf's compatibility semantics. The whole idea of using protobuf is that it allows you to add/remove fields from your protocol definition while still being fully forward/backward compatible with newer/older binaries. Required fields break this though. You can never safely add a required field to a .proto definition, nor can you safely remove an existing required field because both of these actions break wire compatibility. For example, if you add a required field to a .proto definition, binaries built with the new definition won't be able to parse data serialized using the old definition because the required field is not present in old data. In a complex system where .proto definitions are shared widely across many different components of the system, adding/removing required fields could easily bring down multiple parts of the system. We have seen production issues caused by this multiple times and it's pretty much banned everywhere inside Google for anyone to add/remove required fields. For this reason we completely removed required fields in proto3.

After the removal of "required", "optional" is just redundant so we removed "optional" as well.

@yzhao1012
Copy link

After the removal of "required", "optional" is just redundant so we removed "optional" as well.

Note that removing optional does not mean that the "optionality" concept is gone.
The flaw of removing completely the optionality concept is more debatable, as often people want to have the old "has_()" API for testing user intention.

@qia01ng
Copy link

qia01ng commented Nov 12, 2022

We dropped required fields in proto3 because required fields are generally considered harmful and violating protobuf's compatibility semantics. The whole idea of using protobuf is that it allows you to add/remove fields from your protocol definition while still being fully forward/backward compatible with newer/older binaries. Required fields break this though. You can never safely add a required field to a .proto definition, nor can you safely remove an existing required field because both of these actions break wire compatibility. For example, if you add a required field to a .proto definition, binaries built with the new definition won't be able to parse data serialized using the old definition because the required field is not present in old data. In a complex system where .proto definitions are shared widely across many different components of the system, adding/removing required fields could easily bring down multiple parts of the system. We have seen production issues caused by this multiple times and it's pretty much banned everywhere inside Google for anyone to add/remove required fields. For this reason we completely removed required fields in proto3.

After the removal of "required", "optional" is just redundant so we removed "optional" as well.

clearly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants