1

Assuming we have following message that will be used to update data and it just got updated to version 2.

message HelloRequest {
  string name = 1; // version 1
  bool is_valid = 2; // version 2
}

Now assuming we updated our apps like so:

  • server : version 2
  • client A : version 2
  • client B : version 1

We don't have any problems with client A since it can set the proper is_valid value. The issue is that client B will always send a message with is_valid set to false. Is there any techniques such that the server won't use the is_valid field if it's from a version 1 client?

In a RESTful API, I could use PATCH to partially update data. That is, the JSON data will not have the is_valid field, so the server can choose not to change the said field.

Our server will be written in C#, not sure if that needs to be considered with this question.

Jan Paolo Go
  • 119
  • 7

1 Answers1

3

There's an important difference here between "proto2" and "proto3" syntax; you're using "proto3" syntax here (and the Google tooling only supports "proto3" syntax), and in "proto3", zeros are defaults and defaults are zeros; meaning: the only default value for a bool is false, and false is never sent; thus a missing value is false.

So if you're using "proto3", you'll have to invert this and make it is_invalid, then the implicit default of false will work.

In "proto2" you have a few more options here, but: Google's tooling does not support "proto2" on C#. There is non-Google tooling available, and I'm working on having it working nicely with gRPC in time for the .NET Core 3 release.

(technically it would work fine today as long as you're happy to write all the bindings manually)

Marc Gravell
  • 2,827
  • 1
  • 17
  • 14
  • I'm not sure I understand how `is_invalid` makes a difference. If client A updates the resource with `is_invalid` to `true`. Then later, client B updates the same resource, wouldn't `is_invalid` be set to `false` again? **Assuming the resource is an entity in the database – Jan Paolo Go Jul 03 '19 at 14:44
  • @JanPaoloGo unknown fields have been preserved in the Google C# tooling since [v3.6.0](https://github.com/protocolbuffers/protobuf/releases/tag/v3.6.0) - of course, that only applies if you store it *as raw protobuf*; if you store it in an ORM (for example) and recreate the POCO with only the known fields, then yes: you'll burn that – Marc Gravell Jul 03 '19 at 14:50