[hibernate-dev] Fail fast feature for Hibernate Validator

[Gunnar Morling]

Hi,

answers inline.

Gunnar


2010/10/5 Emmanuel Bernard <emmanuel at hibernate.org>

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

I think that's the approach we should go for, as it is BV's standard way for
creating validators configured with custom properties (in addition to
Validation#byProvider() for configuring validator factories).

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();

note that we can also envision something like
>
> ailFastValidator = regularValidator.unwrap(HibernateValidatorFactory.class)
>                                        .usingHibernateContext()
>                                                .failFast(true)
>                                        .getValidator();
>

I don't quite understand this approach, you want to unwrap a validator into
a validator factory? Or do you think of re-configuring a once retrieved
validator? Retrieving a new validator from an existing one seems akward to
me.


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

Agree, this could make things complex quickly, and I don't think one would
need to change the configuration values between two validation calls very
often. And if so, retrieving a newly configured validator in that case seems
acceptable to me. Plus, in a typical project the actual validator is used
way more often than the validator factory. So I guess, most people would
prefer to reference javax.validation.Validator instead of a
provider-specific derivation here.


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