-
Notifications
You must be signed in to change notification settings - Fork 2
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
Fix "continue validation" (list of Pattern validation etc) #270
Conversation
Maybe I'm missing the point here, but don't all of the other existing tests imply the continuation or lack thereof? With the exception of the NotBlank and size adapter, all the adapters extend the isValid method, so continuing or not is determined by the following block. avaje-validator/validator/src/main/java/io/avaje/validation/adapter/AbstractConstraintAdapter.java Lines 33 to 36 in c26a2d3
|
If we change AbstractConstraintAdapter + switch the assertions of the BUG expectations ... the remaining tests that break will be for the NullableAdapter and the NotEmptyAdapter [which both extend AbstractConstraintAdapter but where the expectation is for false - "not continue validation" ] Edit: I'll add a commit to document that. |
…bleAdapter and NotEmptyAdapter to support existing behavior NullableAdapter and NotEmptyAdapter support returning NOT "continue validation"
This is the PR / Change I want to go with first as it is more clear what the behaviour change / bug fix. There are a couple of other changes in PR #269 that I'd like to see as follow up separate PRs so that we are nice and explicit about those behaviour changes. |
Which passes with the prior fixes in place wrt "continue validation"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's deploy an RC to unblock #266
Change AbstractConstraintAdapter to continue validation, Adjust NullableAdapter and NotEmptyAdapter to support existing behaviour
Note that the original failing test was for multiple
@Pattern
validations on the same field. The issue was that the validation would not correctly process the entire chain of validation adapters because some [like the PatternAdapter] were incorrectly returning false to stop the validation when they added a constraint violation.The fix was a combination of changing AbstractConstraintAdapter to continue validation, plus changing NullableAdapter and NotEmptyAdapter to support existing behaviour.