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; > 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&gt; wrote: > > > >> 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... > >> for code examples. > >> > >> Emmanuel > >> > > > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev >