Re: [hibernate-dev] Fail fast feature for Hibernate Validator

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&gt; > 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&gt; > 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&gt; > emmanuel(a)hibernate.org&gt; > >> 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 >> <&lt;emmanuel(a)hibernate.org&gt; >> emmanuel(a)hibernate.org&gt; 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&gt;hibernate-dev(a)lists.jboss.org >> <https://lists.jboss.org/mailman/listinfo/hibernate-dev> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > >