You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Groups are not handled uniformly in the various implementations of protovalidate.
In particular, it looks like the Go and Java implementations do not correctly support groups and will skip validating the data inside a group field. However, Python and C++ implementations do not appear to have this defect.
Test cases should likely be added to the conformance tests to verify they work correctly across all implementations.
In particular, both Go and Java implementations only do "embedded message" validation when the field's type is "message". However, group fields will have a type of "group". The Go code uses an thin abstraction over google.protobuf.protobuf.FieldDescriptorProto.Type named protoreflect.Kind. Similarly, the Java code uses a thin abstraction in the Java enum Descriptor.FieldDescriptor.Type. But they both map to the type enum in descriptor.proto, where message and group each have a distinct value (necessary because though they are structurally the same, representing nested messages, they use different wire encoding formats).
The Python code, however, simply asks if the field descriptor has an associated message type, which it will for both groups and messages. And the C++ code instead looks at the field descriptor's cpp_type(), which will be CPPTYPE_MESSAGE for both messages and groups. So these two implementations appear to correctly support groups. (A new conformance test would be the best way to verify and assert this to be true.)
Like PGV before it, PV does not officially support validation against groups (mainly due to their deprecation status that predates both of these projects). We could add support (or document/test for non-support), but over the past 5 years of these two projects, this is actually the first time they've been mentioned 😅.
I suspect that we'll need to revisit this. While groups are long deprecated, "delimited encoding" is a thing that can be done in Editions files, and I think such fields may look like groups when inspected via the reflection APIs.
Groups are not handled uniformly in the various implementations of protovalidate.
In particular, it looks like the Go and Java implementations do not correctly support groups and will skip validating the data inside a group field. However, Python and C++ implementations do not appear to have this defect.
Test cases should likely be added to the conformance tests to verify they work correctly across all implementations.
In particular, both Go and Java implementations only do "embedded message" validation when the field's type is "message". However, group fields will have a type of "group". The Go code uses an thin abstraction over
google.protobuf.protobuf.FieldDescriptorProto.Type
namedprotoreflect.Kind
. Similarly, the Java code uses a thin abstraction in the Java enumDescriptor.FieldDescriptor.Type
. But they both map to the type enum indescriptor.proto
, where message and group each have a distinct value (necessary because though they are structurally the same, representing nested messages, they use different wire encoding formats).The Python code, however, simply asks if the field descriptor has an associated message type, which it will for both groups and messages. And the C++ code instead looks at the field descriptor's
cpp_type()
, which will beCPPTYPE_MESSAGE
for both messages and groups. So these two implementations appear to correctly support groups. (A new conformance test would be the best way to verify and assert this to be true.)The text was updated successfully, but these errors were encountered: