-
Notifications
You must be signed in to change notification settings - Fork 27
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
Comments
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:
|
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.
The text was updated successfully, but these errors were encountered: