Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature Request] Add an option to set your own descriptor resolver #162

Open
rauanmayemir opened this issue Dec 1, 2024 · 3 comments
Open
Labels
Feature New feature or request

Comments

@rauanmayemir
Copy link

Feature description:

Similar to WithExtensionTypeResolver, it would be helpful to allow adding your own WithDescriptorResolver option.

Problem it solves or use case:

It will allow using dynamic schema registries outside of global protoregistry.Files

Proposed implementation or solution:

Something like:

func WithDescriptors(resolver ...protodesc.Resolver) ValidatorOption {
  return func(cfg *config) {
    cfg.descResolver = resolver
  }
}
@rauanmayemir rauanmayemir added the Feature New feature or request label Dec 1, 2024
@jhump
Copy link
Member

jhump commented Dec 3, 2024

@rauanmayemir, the only way a descriptor resolver might be used is for CEL expressions that operate on google.protobuf.Any messages. Is that the issue you are encountering? If not, please describe the issue you are encountering with dynamic schemas, in case you're running into something else (like a bug).

@rauanmayemir
Copy link
Author

rauanmayemir commented Dec 3, 2024

@jhump No, there was no issue. Apparently, I didn't even have to add my regular message descriptors because the input message already has a ProtoReflect() with all the information, is that correct?

@jhump
Copy link
Member

jhump commented Dec 3, 2024

That's correct. A descriptor resolver is generally unnecessary since the message being validated knows its own descriptor (and all fields therein know their message types, too).

The only time you would run into trouble is when using google.protobuf.Any messages, where the contained message payload is a dynamic message (i.e. not known to the program via protoregistry.GlobalFiles). In this case, there are some operations in CEL expressions that will try to unpack the Any message, which would fail in this case. This is the only case where you would benefit from an option like this, to provide additional dynamic message types to the CEL interpreter so it knows how to unpack them.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants