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.morl...@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 <hibern...@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.morl...@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
>
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
