3 ms·

My understanding is that the powers that be within Google have decided that validating messages is outside the scope of schemas and serialization. protoc-gen-va

My understanding is that the powers that be within Google have decided that validating messages is outside the scope of schemas and serialization. protoc-gen-validate provides a portable way to perform validation: https://github.com/bufbuild/protoc-gen-validate https://github.com/bufbuild/protoc-gen-validate The problem with required fields is it kicks the can down the road when you want to deprecate a field. Keeping everything optional is much, much better for everyone in the long run.

fuzzy2 4y ago
The problem is with default values: they are not sent over the wire. You cannot determine whether that false was deliberate or the sender just forgot to set it to true. I understand that "elastic" contracts may make some stuff easier. They do not help in forcing developers to create a message correctly, unfortunately. Still, it's great to see someone is tackling the validation rule topic. One of my stakeholders is very… enthusiastic about validation. Just goes to show how bad software engineering is in practice in this org.
- tantalor 4y ago
  Er no, that's not true. If you set the value of a field, then it will be serialized with that value. It doesn't matter if the value is the default for that field.
  - fuzzy2 4y ago
    No, it is, at least for C# and the default/"official" code generator. The docs (proto3) say this: “Also note that if a scalar message field is set to its default, the value will not be serialized on the wire.”
    - tantalor 4y ago
      That's true for "singular" fields, but not "optional". https://developers.google.com/protocol-buffers/docs/proto3#specifying_field_rules https://developers.google.com/protocol-buffers/docs/proto3#s... If you don't like that, don't use "singular".
      - fuzzy2 4y ago
        optional or repeated are not semantically correct for a required field though. I’d rather not pollute the contract this way. It doesn’t lend itself to automatically generating documentation from the schema either. Guess I’ll take another look at proto2 then.

fuzzy2 4y ago

The problem is with default values: they are not sent over the wire. You cannot determine whether that false was deliberate or the sender just forgot to set it to true. I understand that "elastic" contracts may make some stuff easier. They do not help in forcing developers to create a message correctly, unfortunately. Still, it's great to see someone is tackling the validation rule topic. One of my stakeholders is very… enthusiastic about validation. Just goes to show how bad software engineering is in practice in this org.

tantalor 4y ago
Er no, that's not true. If you set the value of a field, then it will be serialized with that value. It doesn't matter if the value is the default for that field.
- fuzzy2 4y ago
  No, it is, at least for C# and the default/"official" code generator. The docs (proto3) say this: “Also note that if a scalar message field is set to its default, the value will not be serialized on the wire.”
  - tantalor 4y ago
    That's true for "singular" fields, but not "optional". https://developers.google.com/protocol-buffers/docs/proto3#specifying_field_rules https://developers.google.com/protocol-buffers/docs/proto3#s... If you don't like that, don't use "singular".
    - fuzzy2 4y ago
      optional or repeated are not semantically correct for a required field though. I’d rather not pollute the contract this way. It doesn’t lend itself to automatically generating documentation from the schema either. Guess I’ll take another look at proto2 then.