3 ms·
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
by 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 agoEr 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 agoNo, 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 agoThat'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 agooptional 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.