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

Proto2 primitives should be Option[primitive] #218

Open
TannerYoung opened this issue Jan 27, 2020 · 2 comments
Open

Proto2 primitives should be Option[primitive] #218

TannerYoung opened this issue Jan 27, 2020 · 2 comments

Comments

@TannerYoung
Copy link

syntax = "proto2";

package src.main.hello;

message SayHelloRequest {
  optional string name = 1;
}
message SayHelloResponse {
  optional string message = 1;
}

service HelloWorldService {
  rpc SayHello (SayHelloRequest) returns (SayHelloResponse) {}
}

Should generate case classes with fields which are Option[String] instead of String. There is a semantic difference between what skeuomorph produces and the Proto2 spec. This means that you can't send the "not-set" string/int/bool value with skeuomorph without explicitly passing null (which is awful). This is problematic when dealing with apis that expect a null value be distinguishable from the default value.

See #89 and #92 which fix this for non-primitive types.

@juanpedromoreno
Copy link
Member

Thanks @TannerYoung for the detailed information.

I'm sorry, we are still working on docs, but skeuomorph has been designed aiming proto3 compliance initially. In general, when using skeuomorph along with mu we are recommending proto3 for the gRPC communications.

@TannerYoung
Copy link
Author

Understandable, but worth noting that proto3 is not and never was intended to replace proto2, but is a simpler alternative for some use cases. Proto2 is not deprecated, has no deprecation roadmap, and is used widely with many Google related technologies and even within new projects.

Lots of people assume proto3 > proto2, but it is more nuanced than that and I believe it's worth considering proto2 as not a technology that can be replaced by proto3, but a different technology with stronger controls available.

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

2 participants