[bv-dev] Ordered Validation (practically)

Peter Davis davispw at gmail.com
Wed Jan 4 01:37:33 EST 2012


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 at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> 
> 
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20120103/f75fe14e/attachment.html 


More information about the beanvalidation-dev mailing list