Bug: Enum "in / not_in" in the Map

[yrcs]

The closed #619 issue is still unresolved.

enum Order {
  ASC = 0;
  DESC = 1;
}

message PagingRequest {
  map<string, Order> orderBy = 1 [(validate.rules).map = {ignore_empty: true, keys: {string: {min_len: 1}}, values: {enum: {defined_only: true, in:[0, 1]}}}];
}

[elliotmjackson]

Hi @yrcs, looking at the rule comparison chart in / not_in is not supported in maps at this stage. If you require them, id be happy to review a PR but at this stage we are focused on bugs and language support parity.

[yrcs]

Hi @yrcs, looking at the rule comparison chart in / not_in is not supported in maps at this stage. If you require them, id be happy to review a PR but at this stage we are focused on bugs and language support parity.

OK! Just keep this issue open...

[haines]

looking at the rule comparison chart in / not_in is not supported in maps at this stage

I don't think it's specified in this comparison chart. The chart shows keys and values are supported; it doesn't list all the possible sub-rules that are supported within the keys and values.

I'd argue that this is a bug, not a lack of a feature, because pgv doesn't ignore in/not_in, or throw an error indicating that they are not supported - it exits successfully having generated code that then fails to compile.

[yrcs]

@haines You're right, it's a bug. And I solved it temporarily by adding the following variables to the generated *.pb.validate.go file.

var _PagingRequest_OrderBy_InLookup = map[Order]struct{}{
    0: {},
    1: {},
}

[rolandcxc]

@elliotmjackson I have encountered the same problem with IDLs like this one.

message CreateTextRequest {
  map<string, string> texts = 1 [(validate.rules).map.keys.string = { in: [ "en", "zh" ] }];  
};

The definition of _CreateTextRequest_Texts_InLookup is missing from the generated go code.

	if _, ok := _CreateTextRequest_Texts_InLookup[key]; !ok {
		err := CreateTextRequestValidationError{
			field:  fmt.Sprintf("Texts[%v]", key),
			reason: "value must be in list [en zh]",
		}
		if !all {
			return err
		}
		errors = append(errors, err)
	}

Can this issue be fixed?

[m430]

Same problem +1

[elliotmjackson]

Good news! this has since been resolved in our protovalidate project. I'm pleased to let you know that protovalidate is where we're focusing our efforts for the future.

Given the improvements and advancements in protovalidate, I recommend considering migration to this newer version. It offers a more comprehensive and user-friendly experience within the Protobuf ecosystem.