Hi,
a use case might be a data-centric application, where you for performance
reasons don't want to validate graphs completely once a failure occured, but
don't want to face the user with single validation errors one after the
other either.
Specifying the validation order would surely be useful. But I wouldn't tie
these things together. I suggest to introduce a numeric parameter and for a
start either make clear that the validation order is not specified or only
support values 0 (don't stop on first error) and 1 (= failFast). Later on,
if validation order is spec'd, other values than these could easily be
supported. If we now introduce a boolean parameter, the API would be
somewhat "polluted" if we come up with a numeric parameter later on. Then we
either had two parameters (leaving space for inconsistent configurations) or
had to remove the boolean parameter again.
Gunnar
2010/10/4 Emmanuel Bernard <emmanuel(a)hibernate.org>
Ive been toying with the number idea while talking with Max.
Im not sure what use case that solves provided the highly unpredictable
nature of what's get returned.
It might be more useful and get a usecase if we spec what gets returned
roughly. Like deep-last algorithm etc.
On 4 oct. 2010, at 22:17, Gunnar Morling <gunnar.morling(a)googlemail.com>
wrote:
Hi,
I like the idea. Emmanuel's performance test showed an execution time per
validation of 11 vs. 74 ms on my system, so there seems to be some
potential. Instead of having a "failFast" flag one could also introduce a
numeric parameter to control, when validation should stop. A value of "1"
would be equal to the flag being true, but one could also decide to stop
just after 3 validation errors for instance.
Gunnar
2010/10/4 Emmanuel Bernard < <emmanuel(a)hibernate.org>
emmanuel(a)hibernate.org>
> That or slowish validations.
>
> One typical use case is that:
>
> if ( validator.validate(customer, StraightToValidationScreen.class).size()
> >0 ) {
> //manual process
> }
> else {
> //automatic process
> }
>
> BTW, I've committed a non scientific perf test that shows an average of 5x
> perf improvement on an object graph of 5 object (one master and 4 children)
> and 4 constraints on A and 3 on B. Around 22ms vs 120 ms. (log4j logs set to
> ERROR). The perf change is visible even on smallish graphs.
>
> It can be worthwhile.
>
> On 4 oct. 2010, at 16:20, Hardy Ferentschik wrote:
>
> > What would be the usecase? Saving time in large object graphs where I am
> only interested in whether there is a
> > failure at all? You really need LARGE object graphs to make this worth
> while.
> >
> >
> > On Mon, 04 Oct 2010 15:45:34 +0200, Emmanuel Bernard
<<emmanuel(a)hibernate.org>
> emmanuel(a)hibernate.org> wrote:
> >
> >>
> <
http://github.com/emmanuelbernard/hibernate-validator/commits/failFast>
>
http://github.com/emmanuelbernard/hibernate-validator/commits/failFast
> >>
> >> What do you guys think?
> >>
> >> The idea is to stop a the first failure.
> >> You can enable that :
> >> - by property
> >> - at config time
> >> - when the Validator is created
> >>
> >> Look at
> >>
>
<
http://github.com/emmanuelbernard/hibernate-validator/blob/failFast/hiber...
>
http://github.com/emmanuelbernard/hibernate-validator/blob/failFast/hiber...
> >> for code examples.
> >>
> >> Emmanuel
> >>
> >
>
>
> _______________________________________________
> hibernate-dev mailing list
> <hibernate-dev@lists.jboss.org>hibernate-dev(a)lists.jboss.org
> <
https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>
https://lists.jboss.org/mailman/listinfo/hibernate-dev
>