12:37 a.m.
Hello,
Been lurking a while. I have also struggled to control ordering like Cemo. Unfortunately
a global "short circuit" setting is not sufficient for my enterprise (a number
of reasons, but this email is already long enough).
Here's my 1st suggestion. This would solve the use case of "prerequisite
validations" (see
http://relation.to/Bloggers/JSRBeanValidation11WhatToPutIn#comment22221 for example), as
well as most use cases of "cheap vs. expensive" provided you don't need
different messages. Also, IMHO it is overdue: not short circuiting (as today) is totally
redundant. Is there a reason this wasn't specified for BV 1.0?
"When @ReportAsSingleViolation is present, short circuit."
so
@Size(5)
@Pattern("[0-9]{5}")
@Constraint(validatedBy=BusinessPostCodeValidator.class) // expensive; query explodes if
size > DB column length
@ReportAsSingleViolation // only query DB if @Size and @Pattern pass
public @interface PostCode { ...
String message() default "not a valid postal code";
}
If different messages are needed, then @GroupSequence works but as Cemo says is unwieldy,
and furthermore in practice breaks when combined with group inheritance (which is very
natural and useful). So...2nd suggestion:
"Allow @GroupSequence to be combined with interface inheritance in the obvious
way."
(OK, "obvious" has a lot of nasty edge cases, but let me demonstrate why this
would be a good change:)
Currently the following gives wacky and IMHO wrong results (test case available on
request). A close reading of BV 1.0 spec shows @GroupSequence and inheritance are
incompatible...but the interactions are not intuitive:
@GroupSequence({Name1.class, Name2.class, Name3.class})
interface Names {
interface Name1 {}
interface Name2 {}
interface Name3 {}
}
@GroupSequence({Surname1.class, Surname2.class, Surname3.class})
interface Surnames {
interface Surname1 {}
interface Surname2 {}
interface Surname3 {}
}
interface BusinessValidations extends Names, Surnames {}
// At least the client wouldn't have to see all the ugliness.
// Maintenance, extensibility improved...but the following doesn't work!
// Currently no warning/error; only discover failure by test cases.
validator.validate(account, BusinessValidations.class);
From my perspective proposal #1 would get 80% of the way, and #2 would get the rest as
well as solve some very wacky (buggy?) interactions I've observed in my year+ of using
BV 1.0. [There are other, more subtle ways that @GroupSequence messes with inheritance --
even when used in unrelated groups passed to #validate(...) -- that I'd be happy to
move to a different topic.]
Thanks for a great product!
Regards,
Peter Davis
On 3-Jan-2012, at 13:12 , Gerhard Petracek wrote:
hi,
actually we had a related discussion about it for bv v1.0.
(the topic was "sort-circuit" and one suggestion was to introduce e.g.
ValidatorContext#failAtFirstViolation)
+1 for re-visiting this topic.
regards,
gerhard
2012/1/3 Cemo <cemalettin.koc(a)gmail.com>
Hi experts,
After reading your comments and mail list I realized that it will be better share our
opinions here about our problems.
First, I would like to thanks all of you to provide such an elegant library and spec.
After latest improvements at spring side, I am sure that bean validation will be defacto
validation framework among java community.
The only problem We are facing is that ordered validations.
In a common sense validation such this can be feasible:
public class AccountBean {
@CheapValidation(groups=Name1.class)
@ExpensiveValidation(groups=Name2.class)
@VeryExpensiveValidation(groups=Name3.class)
String name;
@CheapValidation(groups=Surname1.class)
@ExpensiveValidation(groups=Surname2.class)
@VeryExpensiveValidation(groups=Surname3.class)
String surname;
public interface Name1 {}
public interface Name2 {}
public interface Name3 {}
@GroupSequence({Name1.class, Name2.class, Name3.class})
public interface Name {}
public interface Surname1 {}
public interface Surname2 {}
public interface Surname3 {}
@GroupSequence({Surname1.class, Surname2.class, Surname3.class})
public interface Surname {}
}
There is two common usage for this. The first usage: some validations are expensive that
should be runned if all validations pass. Another usage is for each field there should be
one violation. For email, if it is empty, uniqueEmail constraint must not be checked. I
hope that how much necessary it is for us you can imagine. Almost all fields has such
restrictions. Ordering and shortcutting are crucial for us.
But just to provide validation order and shortcut GroupSequence is practically
impossible to use at enterprice level. For each field again and again we are declaring
interfaces. It is not only intuitive but also seems ugly. By the way what is came to my
mind is for each constraint, declaring a order like this:
public class AccountBean {
@CheapValidation(order=0,groups=Name1.class)
@ExpensiveValidation(order=1,groups=Name2.class)
@VeryExpensiveValidation(order=2,groups=Name3.class)
String name;
@CheapValidation(order=0,groups=Surname1.class)
@ExpensiveValidation(order=1,groups=Surname2.class)
@VeryExpensiveValidation(order=2,groups=Surname3.class)
String surname;
}
Default value for ordering might be same for all constraints.
Please help community. :)
Thanks & happy new year
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev