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

adopt proto3 optional - explicit field presence #964

Open
eric846 opened this issue Jan 10, 2023 · 0 comments
Open

adopt proto3 optional - explicit field presence #964

eric846 opened this issue Jan 10, 2023 · 0 comments
Labels
enhancement New feature or request

Comments

@eric846
Copy link
Contributor

eric846 commented Jan 10, 2023

proto3 has restored optional, so for a field

syntax = "proto3";
message X {
  optional bool mybool = 1;
}

we regain the ability to distinguish between

  • primitive field unset (has_mybool() false)
  • primitive field explicitly set to default value (has_mybool() true, mybool() false)

as in proto2.

optional is optional. If a field is marked optional in proto3, we get the proto2 behavior.

See https://developers.google.com/protocol-buffers/docs/proto3#specifying_field_rules.

We should consider adopting optional, moving away from wrappers like google.protobuf.UInt32Value.

If we created a clean proto, it could just be like:

syntax = "proto3";
message BenchmarkSpec {
  optional uint32 requests_per_second = 1 [(validate.rules).uint32 = {gte: 1, lte: 1000000}];
  optional uint32 connections = 2 [(validate.rules).uint32 = {gte: 1, lte: 1000000}];
  // ...

The gRPC service would be surprisingly easy to update. Maybe:

message StartRequest {
  oneof opts {
    CommandLineOptions options = 1;
    BenchmarkSpec benchmark_spec = 2;
  }
}
@eric846 eric846 added the enhancement New feature or request label Jan 10, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant