0

I'll be able to answer this question myself once I get this service running but I was surprised I couldn't find an answer on SO, at least by the keywords I was searching. The problem is if you search anything about protobufs and requiredness / optionality, you get flooded with answers about proto3 making all fields optional. I could not find an answer specifically about validation rules.

Considering the use of validate/validate.proto...

message Batch {
  string name = 1 [(validate.rules).string = { min_len:1, max_len:64}];
  int64 minimum_spend_micro = 2 [(validate.rules).int64.gte = 1];
  google.protobuf.Timestamp start_time = 3 [(validate.rules).timestamp.required = true];
  PromoCodeType code_type = 4 [(validate.rules).enum.defined_only = true];
  int32 limit = 5 [(validate.rules).int32.gte = 1];
}

...do the example validations above all effectively enforce requiredness? Or does it depend on the type? (e.g. I can imagine a string being defaulted to null which still passes, but integers and enums defaulting to 0 which fails.)

Andrew Cheong
  • 29,362
  • 15
  • 90
  • 145

1 Answers1

1

Ah, I believe you're using the protoc-gen-validate extensions to Protocol Buffers. This is something that I dearly wished Google would adopt into the mainstream of GPB, because the lack of validation rules is a big omission in GPB.

My understanding is that the validation rules allow you to override the "everything is optional" aspect of proto3. For example, for an numerical field in a message, you can have a rule:

unint32 x = 1 [(validate.rules).uint32 = {ignore_empty: false}];

My understanding is that the ignore_empty: false component of the rule means that it will fail validation if it's not set. This rule can be combined with others, so that validation ranges can be tested:

unint32 x = 1 [(validate.rules).uint32 = {ignore_empty: false, gte: 200}];

The ignore_empty rule seems to be available for all basic types, except (for some reason) bool. Though, that might just be an oversight in the documentation; could be worth a go.

Enums can be forced to be set to one of the enum values, which amounts to the same as "it must be set to a value". Here, a field called x of enumeration type State must be defined:

State x = 1 [(validate.rules).enum.defined_only = true];

For fields that are messages:

Person x = 1 [(validate.rules).message = {required: true}];

Which means a field called x of type Person must be set, otherwise validation fails.

So I think the answer to your question "In proto3, can validate.rules enforce requiredness?" is yes, except possibly for boolean fields. I've not tried any of this myself, but from reading the docs I think that's how it should work.

bazza
  • 7,580
  • 15
  • 22
  • Thank you! I didn't realize these came from an extension. – Andrew Cheong Apr 14 '23 at 11:33
  • 1
    @AndrewCheong, no worries, good luck :-) Yes, it's an extension, which comes with the exciting possibility of editing the source for the extension oneself and adding whatever validation rules one wants! Also, a useful thing to bear in mind is that the validation rules do not alter the wireformat in anyway whatsoever. Your schema stripped of validation rules can be given to someone else, and they can use that to build code and read your data (except they cannot validate messages). – bazza Apr 14 '23 at 12:55