Feature: nested struct validation #1122
Conversation
…g variants on structs containing uncomparable types such as maps or slices Also added a test to (partially) cover this case.
|
Thanks for the PR @MysteriousPotato! I like the approach here and yes fields after valid struct is the order that's required to not cause breaking changes. Going to let it sit with me for a big to digest. |
|
@MysteriousPotato I really like this PR! If you can update the tests I'd be happy to merge this :) |
|
@deankarn Great! There are now tests for all tags that are compatible with this implementation of nested struct validation. This inlcudes the tags below:
I did not make a lot of changes to the documentation except a few places where the behavior is specified for each type. Let me know if you want the documentation to be more explicit about the behavior. |
|
Awesome @MysteriousPotato! I will try and review early this week :) |
|
Sorry I haven’t forgotten about this, just been a heck of a week thus far, still high on my list :) |
## PR This PR does the following: - Reverts #1122 - Re-implements struct level validations in a different way which also support `or`s etc.. which previous implementation did not. - Adds special case to ignore `required` validation on non-pointer structs to preserve pre-struct level tag validation support. - Added new `WithRequiredStructEnabled` option to opt-in to this new behaviour, that will become the default in the next major version.
Fixes #367, #906
Make sure that you've checked the boxes below before you submit PR:
A test has been added for custom tags, however I was not brave enough to actually update the tests for all required/excluded tag variants before getting an initial feedback, but I'm willing to do so if this ever gets any further.
Same goes for documentation.
The implementation supports both struct and struct pointer validations for custom tags and all required/excluded tag variants.
Struct validity is evaluated first and fields are evaluated only if the struct is valid, though I'm not sure if this is the desired behavior.
@go-playground/validator-maintainers