[hibernate-dev] Fail fast feature for Hibernate Validator

[Emmanuel Bernard]

Not rebuild the factory, reusing it.

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

note that we can also envision something like

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 at googlemail.com> 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 at ferentschik.de>
>> 
>>> 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 at googlemail.com> 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
> 
>