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 <emman...@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.morl...@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 < <emman...@hibernate.org>
> emman...@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
>> > <<emman...@hibernate.org>
>> emman...@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/hibernate-validator/src/test/java/org/hibernate/validator/test/engine/failFast/FailFastTest.java>
>> http://github.com/emmanuelbernard/hibernate-validator/blob/failFast/hibernate-validator/src/test/java/org/hibernate/validator/test/engine/failFast/FailFastTest.java
>> >> for code examples.
>> >>
>> >> Emmanuel
>> >>
>> >
>>
>>
>> _______________________________________________
>> hibernate-dev mailing list
>> <hibernate-dev@lists.jboss.org>hibernate-dev@lists.jboss.org
>> <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
