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] Support validation of extension fields #116

Open
jhump opened this issue Oct 24, 2023 · 1 comment
Open

[Feature Request] Support validation of extension fields #116

jhump opened this issue Oct 24, 2023 · 1 comment
Labels
Feature New feature or request

Comments

@jhump
Copy link
Member

jhump commented Oct 24, 2023

Currently, all four implementations (Go, Java, Python, and C++) ignore extension fields.

Ideally, when building the evaluator for a message, if a message is extendable (its descriptor defines at least one extension range), an additional message-level evaluator would be instantiated whose implementation loops through all present extensions and recursively validates them. Not only should this apply field constraints to the extension fields, but it should also recursively validate nested messages, for extensions whose type is a message (or a list of messages or a map with message values).

Currently, evaluators are created and cached on a per-message basis. Computing an evaluator for a message constructs sub-evaluators for all fields and oneofs. We will need to either augment this to support to creating/caching evaluators keyed by an extension FieldDescriptor or the message evaluator needs to be mutable (at least when "lazy-loading" of evaluators is enabled), so that add'l extension field evaluators can be added as new extensions are encountered when validating message instances.

In order to properly support non-lazy validators, where all constraints must be defined up front, the APIs should be updated to accept extension FieldDescriptors up-front, in addition to accepting the set of known message types up-front. That way, rules can be built ahead-of-time for these extension fields and applied to the relevant messages.

@jhump jhump added the Feature New feature or request label Oct 24, 2023
@jhump
Copy link
Member Author

jhump commented Oct 24, 2023

FWIW, it looks like the C++ runtime will actually recursively validate nested messages in extension field values. Unlike the other implementations, which statically build the evaluators for nested messages based on the known field descriptors, the C++ implementation uses reflection to iterate set fields and recursively evaluates messages it discovers that way. It does not actually validate field constraints on the extensions though -- but it will evaluate constraints inside message values.

Relevant links:

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

1 participant