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 >> > >

public doStuff(@Param("name") String name, @Param("command") Object command) { ... } On 5 oct. 2010, at 16:07, Hardy Ferentschik wrote: > Where exactly do you want to add the parameter? To the Validator.validateXYZ() methods? > > > On Tue, 05 Oct 2010 15:54:10 +0200, Gunnar Morling <gunnar.morling(a)googlemail.com&gt; wrote: > >> 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 >>>> >>> >>> > _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

I was about to ask what you've been smoking ;-)

On Tue, 05 Oct 2010 17:45:23 +0200, Emmanuel Bernard <emmanuel(a)hibernate.org&gt; wrote: > oops reading Gunnar's answer, I'm probably answer the wrong question :) > > On 5 oct. 2010, at 17:23, Emmanuel Bernard wrote: > >> public doStuff(@Param("name") String name, @Param("command") Object >> command) { >>    ... >> } _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

I'd put it at the same place as the boolean parameter in Emmanuel's prototype: when creating the ValidatorFactor/Validator (e.g. inHibernateValidatorConfiguration). So "parameter" was not meant as in "method parameter" but more as in "configuration attribute" :-) 2010/10/5 Hardy Ferentschik <hibernate(a)ferentschik.de&gt; > Where exactly do you want to add the parameter? To the > Validator.validateXYZ() methods? > > > > On Tue, 05 Oct 2010 15:54:10 +0200, Gunnar Morling < > gunnar.morling(a)googlemail.com&gt; wrote: > > 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

Not rebuild the factory, reusing it. regularValidator = factory.getValidator(); failFastValidator = factory.unwrap(HibernateValidatorFactory.class) .usingHibernateContext() .failFast(true) .getValidator();

ailFastValidator = regularValidator.unwrap(HibernateValidatorFactory.class) .usingHibernateContext() .failFast(true) .getValidator();

I am not historically a big fan of method overloading as it creates method explosions when new options come in. Look at JPA 2's EntityManager. It's horrible!

On 5 oct. 2010, at 17:56, Hardy Ferentschik wrote: > Ok. Makes sense. > But why not overloading the validate methods? This way you can with the same Validator dynamically change the > maximum number of failing constraints. In Emmanuel's case you would have to rebuilt the factory. > > --Hardy > > On Tue, 05 Oct 2010 17:42:41 +0200, Gunnar Morling < gunnar.morling(a)googlemail.com&gt; wrote: > >> I'd put it at the same place as the boolean parameter in Emmanuel's >> prototype: when creating the ValidatorFactor/Validator (e.g. >> inHibernateValidatorConfiguration). >> So "parameter" was not meant as in "method parameter" but more as in >> "configuration attribute" :-) >> >> 2010/10/5 Hardy Ferentschik <hibernate(a)ferentschik.de&gt; >> >>> Where exactly do you want to add the parameter? To the >>> Validator.validateXYZ() methods? >>> >>> >>> >>> On Tue, 05 Oct 2010 15:54:10 +0200, Gunnar Morling < >>> gunnar.morling(a)googlemail.com&gt; wrote: >>> >>> 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 > >

Too sad, that javax.validation.ValidatorContext is not defined as public interface ValidatorContext <V extends ValidatorContext<V>> { } If it were, we wouldn't need a dedicated method HibernateValidatorFactory#usingHibernateContext(), but HibernateValidatorFactory could be defined as public interface HibernateValidatorFactory extends ValidatorFactory { HibernateValidatorContext usingContext(); } then, allowing the validator to be retrieved like that: failFastValidator = factory.unwrap(HibernateValidatorFactory.class) .usingContext() .maxConstraintViolationCount(5) .getValidator(); Yes I've hesitated back in the days and thought unwrap was enough :( I wonder if we can retroactively enhance it without breaking clients.

If we /really/ want stopAfterNFailures, I'd go straight to it. It's easy to implement and will confuse people less. But the number of failures will be a guaranteed to be above int (if there are enough ;) ) and the order will be unspecified though today we do breadth-first I believe which is what most people will want. I am still not 100% foreseeing why a UI would want 5 errors at most :) Max, want to weight in?

On 5 oct. 2010, at 15:54, Gunnar Morling wrote: > 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 >> >