Re: [hibernate-dev] Fail fast feature for Hibernate Validator
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(a)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(a)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(a)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