[bv-dev] Ordered Validation (practically)

Cemo cemalettin.koc at gmail.com
Thu Jan 5 06:56:29 EST 2012


Thanks for summing up.

1. I am not sure whether I file another issue or not but if there is an
opportunity I would like set error message via violating constraint. :)

@ReportAsSingleViolation(shortCircuit=true,
messageSource=ByOriginatingConstraint)


2. As you stated the intuitive approach is simple integer value. But maybe
It can be nice too

   @NotEmpty()
   @IsValidBinCodeNumber()
   @IsCardBannedNumber()
   @IsValidCardNumber()

   *@ConstraintSequence(value={NotEmpty.class,* IsValidBinCodeNumber
*.class,IsCardBannedNumber.class, IsValidCardNumber.class},
shortCirtcuit=true)*

   private String creditCard;

This approach is elegant for me. By the way Have you ever considered
partial validation by ordered validation? Current solution based on
Interfaces are simply killing :)

Thanks



On 5 January 2012 12:59, Hardy Ferentschik <hardy at hibernate.org> wrote:

> We are talking about two things here, right?
>
> 1. That the validation of composed constraints should stop immediately if
> @ReportAsSingleViolation is specified and the first failing constraints has
> occurred. That's BVAL-259
>    BVAL-220 is an extension of BVAL-259 which makes the behavior
> configurable via something like this
> @ReportAsSingleViolation(shortCircuit=true)
>    The spec currently keeps the behavior open by saying (page 11, 2.3
> Constraint composition):
>    "If a composing constraint fails and if the composed constraint is
> marked as @ReportAsSingleViolation, the Bean Validation provider is free to
> not process the other composing
>    constraints for this composed constraint."
>
> 2. The ability to define an order in which constraints are getting applied
> (either on a single property or also in connection of a composed
> constraint). That's BVAL-248 (and HV-462).
>     Here we have so far the idea of an additional order parameter added to
> constraints, e.g. @Size(max=100, validationOrder="1") and Emmanuel's
> @GroupSequence(value={Cheap.class,Expensive.class}, ordering=PER_TARGET)
>
>
> Regarding 1, I think implementing BVAL-259 and BVAL-220 makes sense. In
> this context we should, however, also discuss boolean composition
> (BVAL-260) of constraints.
>
> Regarding 2, Emmanuel's idea seems more in the spirit of the current spec
> design, but I disagree that the interface approach is easier to manage the
> order property. I think that Cemo has a point
> that juggling all these interfaces around is at no means easier.  Given
> that we talk about a order specific for a property I think it is easiest to
> understand if you you can specify and see it right there on
> the constraint specified at the property.
>
> --Hardy
>
>
> On Jan 5, 2012, at 11:28 AM, Emmanuel Bernard wrote:
>
> > I have not seen your proposal till now.
> >
> >
> https://hibernate.onjira.com/browse/BVAL-220?focusedCommentId=42681&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-42681
> >
> > This looks quite elegant and only require BVAL-259 to be solved. Peter's
> proposal makes it work for any type and any definition of "null". The only
> drawback is that's it's more subtle / cryptic than an explicit param or
> annotation.
> >
> > On 4 janv. 2012, at 16:46, Peter Davis wrote:
> >
> >> Can the proposal for special null/empty handling be generalized?  I
> have two extra use cases,
> >>
> >> - Concept of "empty" for objects, for example my enterprise often uses
> a "money" object (value+currency)
> >> - Need to define "prerequisite" validations in general, for example
> check @NotNull+ at Size before a DB query to avoid a query exception
> >>
> >> Regards,
> >> Peter Davis
> >>
> >> On Jan 4, 2012, at 5:29, Emmanuel Bernard <emmanuel at hibernate.org>
> wrote:
> >>
> >>> Hi,
> >>> Let me try and summarize what you want to be sure we are on the same
> page:
> >>>
> >>> - you want sometimes to return one and only one failure per property
> >>> - you want some constraints to be validated before others (to be the
> one displayed)
> >>>
> >>> Besides not empty which should be simply ignored by your unique email
> constraint, do you have other use cases? I would rather exclude null /
> empty from the list of use cases because it's a fairly pathological case
> and we plan on addressing that via a different mechanism (namely a way to
> mark a constraint validator as being called only on non null / non empty
> values).
> >>>
> >>> I've been trying to avoid numerical ordering (the fancy name is
> salience I believe) so far so I'd like to see concrete use cases that
> cannot be solved otherwise.
> >>>
> >>> Having a per property shortcut and a global shortcut would be a nice a
> easy feature to add. We left it out of 1.0 but it almost made it through.
> >>>
> >>> Likewise, we could fake salience by providing a special group
> >>>
> >>> ```
> >>> package javax.validation.groups;
> >>>
> >>> @GroupSequence({Level1.class, Level2.class, Level3.class,
> Level4.class, Level5.class, Level6.class, Level7.class, Level8.class,
> Level9.class, Level10.class})
> >>> interface Order {
> >>>     interface Level1 {}
> >>>     interface Level2 {}
> >>>     interface Level3 {}
> >>>     ...
> >>>     interface Level10 {}
> >>> }
> >>> ```
> >>>
> >>> Frankly I'd rather avoid it but that would work.
> >>>
> >>> On 3 janv. 2012, at 21:33, Cemo wrote:
> >>>
> >>>> 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
> >> _______________________________________________
> >> 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
>
>
> _______________________________________________
> 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/20120105/db0347fe/attachment.html 


More information about the beanvalidation-dev mailing list