Skip to content

Tags: bufbuild/protovalidate

Tags

v0.10.0

Toggle v0.10.0's commit message

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature.
Add BCR manifest and bzlmod E2E test (#298)

I'm not really sure if this will work, it looks like we'll have to wing
it and see what happens.

tools/v0.10.0

Toggle tools/v0.10.0's commit message

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature.
Add BCR manifest and bzlmod E2E test (#298)

I'm not really sure if this will work, it looks like we'll have to wing
it and see what happens.

v0.9.0

Toggle v0.9.0's commit message

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature.
Add structured field and rule paths to Violation (#265)

This PR introduces a new structured field path format, and uses it to
provide a structured path to the field and rule of a violation.

- The new message `buf.validate.FieldPathElement` is added.
- It describes a single path segment, e.g. equivalent to a string like
`repeated_field[1]`
- Both the text name and field number of the field is provided; this
allows the field path to be rendered into a string trivially without the
need for descriptor lookups, and will work for e.g. unknown fields.
(Example: A new field is marked required; old clients can still print
the field path, even if they do not have the new field in their schema.)
- It also contains the kind of field, to make it possible to interpret
unknown field values.
- Finally, it contains a subscript oneof. This contains either a
repeated field index or a map key. This is needed because maps in
protobuf are unordered. There are multiple map key entries, one for each
distinctly encoded valid kind of map key.
- The new message `buf.validate.FieldPath` is added. It just contains a
repeated field of `buf.validate.FieldPathElement`
- It would be possible to just have `repeated
buf.validate.FieldPathElement` anywhere a path is needed to save a level
of pointer chasing, but it is inconvenient for certain uses, e.g.
comparing paths with `proto.Equal`.
- Two new `buf.validate.Violation` fields are added: `field` and `rule`,
both of type `buf.validate.FieldPath`. The old `field_path` field is
left for now, but deprecated.
- The conformance tests are updated to match the expectations.

Note that there are a number of very subtle edge cases:
- In one specific case, field paths point to oneofs. In this case, the
last element of the fieldpath will contain only the field name, set to
the name of the oneof. The field number, field type and subscript fields
will all be unset. This is only intended to be used for display
purposes.
- Only field constraints will output rule paths, because it is a
relative path to the `FieldConstraints` message. (In other cases,
`constraint_id` is always sufficient anyways, but we can change this
behavior later.)
- Custom constraints will not contain rule paths, since they don't have
a corresponding rule field. (Predefined constraints will contain rule
paths, of course.)

Implementations:
- bufbuild/protovalidate-go#154
- bufbuild/protovalidate-python#217
- bufbuild/protovalidate-cc#63

tools/v0.9.0

Toggle tools/v0.9.0's commit message

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature.
Add structured field and rule paths to Violation (#265)

This PR introduces a new structured field path format, and uses it to
provide a structured path to the field and rule of a violation.

- The new message `buf.validate.FieldPathElement` is added.
- It describes a single path segment, e.g. equivalent to a string like
`repeated_field[1]`
- Both the text name and field number of the field is provided; this
allows the field path to be rendered into a string trivially without the
need for descriptor lookups, and will work for e.g. unknown fields.
(Example: A new field is marked required; old clients can still print
the field path, even if they do not have the new field in their schema.)
- It also contains the kind of field, to make it possible to interpret
unknown field values.
- Finally, it contains a subscript oneof. This contains either a
repeated field index or a map key. This is needed because maps in
protobuf are unordered. There are multiple map key entries, one for each
distinctly encoded valid kind of map key.
- The new message `buf.validate.FieldPath` is added. It just contains a
repeated field of `buf.validate.FieldPathElement`
- It would be possible to just have `repeated
buf.validate.FieldPathElement` anywhere a path is needed to save a level
of pointer chasing, but it is inconvenient for certain uses, e.g.
comparing paths with `proto.Equal`.
- Two new `buf.validate.Violation` fields are added: `field` and `rule`,
both of type `buf.validate.FieldPath`. The old `field_path` field is
left for now, but deprecated.
- The conformance tests are updated to match the expectations.

Note that there are a number of very subtle edge cases:
- In one specific case, field paths point to oneofs. In this case, the
last element of the fieldpath will contain only the field name, set to
the name of the oneof. The field number, field type and subscript fields
will all be unset. This is only intended to be used for display
purposes.
- Only field constraints will output rule paths, because it is a
relative path to the `FieldConstraints` message. (In other cases,
`constraint_id` is always sufficient anyways, but we can change this
behavior later.)
- Custom constraints will not contain rule paths, since they don't have
a corresponding rule field. (Predefined constraints will contain rule
paths, of course.)

Implementations:
- bufbuild/protovalidate-go#154
- bufbuild/protovalidate-python#217
- bufbuild/protovalidate-cc#63

v0.8.2

Toggle v0.8.2's commit message

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature.
Add more predefined rules conformance tests around repeated fields (#258

)

This uncovers a minor bug in predefined rules on repeated fields that
will need to be fixed in protovalidate-go.

tools/v0.8.2

Toggle tools/v0.8.2's commit message

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature.
Add more predefined rules conformance tests around repeated fields (#258

)

This uncovers a minor bug in predefined rules on repeated fields that
will need to be fixed in protovalidate-go.

v0.8.1

Toggle v0.8.1's commit message

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature.
Revert "Revert protovalidate-testing changes" (#256)

Reverts #254

v0.8.0

Toggle v0.8.0's commit message

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature.
Revert protovalidate-testing changes (#254)

Reverts the protovalidate-testing changes back to the state it was in on
v0.7.1. This won't compile but is needed so that the main module can be
updated independently.

tools/v0.8.1

Toggle tools/v0.8.1's commit message

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature.
Revert "Revert protovalidate-testing changes" (#256)

Reverts #254

v0.7.1

Toggle v0.7.1's commit message

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature.
Fixes for strict conformance with Editions (#226)

I accidentally did not test with the `--strict*` flags set and left a
couple of copy-paste errors :( Oops!

This should now pass as expected with updated implementations.