[hibernate-dev] Fail fast feature for Hibernate Validator

[Hardy Ferentschik]

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