Re: [hibernate-dev] On possible extensions for the validator
Hi again, I was just wondering whether I should interpret the lack of answers as "no, this is not interesting at all", or as "we have a lot of other things to do and do not have time for this right now"? Federico Den 22.09.2010 09:08, skrev Federico Mancini: >Hi all, > I am new to the list and I am opening this thread on Emmanuel Bernard's > suggestion, in order to > discuss some possible extensions to the validator (jsr 303) I have been > working on with a couple of collegues. > Mainly it concerns the possibility to extend composition with boolean > operators (ex.: A field is either in the range 1-10 OR 20-30 AND > notNull) and allow validation of sets of interdependent properties > (ex.: EITHER the name field is notNull OR the surname field is notNull/ > AT LEAST 1 field must be filled/etc). > > A description of the experimental framework we implemented can be found > here http://www.ii.uib.no/publikasjoner/texrap/pdf/2009-389.pdf , and > some further discussion on the choices we made here > http://www.ii.uib.no/~federico/papers/Annotations.pdf. > > I hope this might be of some interest for the Hybernate Validator project, > but, even if not, it would be nice to get some feedback. > > Thanks, > Federico Mancini > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] On possible extensions for the validator
Hi Frederico,
sorry for the late reply. I finally had some time to read through your
paper.
I think there are strong similarities between you work and Hibernate
Validator or
more specific the Bean Validation specification (JSR 303).
Property validation in the SHIP Validator is basically the same as in Bean
Validation.
And what you call cross-annotations would be a class level validator in
Bean Validation terms.
Bean Validation also offers constraint composition similar to what is
described in your paper.
What Bean Validation does not offer is a boolean composition of the
constraints. Here conjunction of
constraints is always assumed.
We are not able to do something like this:
@BoolTest(BoolType.OR)
@Null
@Max(10)
@Target({ METHOD, FIELD })
@Retention(RUNTIME)
@Constraint(validatedBy = { })
public @interface NullOrMax {
public abstract String message() default "foo";
public abstract Class[] groups() default { };
public abstract Class[] payload() default { };
@OverridesAttribute(constraint = Max.class, name = "value")
public abstract long max()
}
Also the ability to validate a subset of all properties from within a
class level validator sounds interesting.
We could implement these features as Hibernate Validator specific
extensions.
Are you interested in getting involved?
--Hardy
On Tue, 05 Oct 2010 09:48:15 +0200, Federico Mancini
wrote:
> Hi again,
> I was just wondering whether I should interpret the lack of answers as
> "no, this is not interesting at all", or as "we have a lot of other
> things to do and do not have time for this right now"?
>
> Federico
>
> Den 22.09.2010 09:08, skrev Federico Mancini:
>>Hi all,
>> I am new to the list and I am opening this thread on Emmanuel Bernard's
>> suggestion, in order to
>> discuss some possible extensions to the validator (jsr 303) I have been
>> working on with a couple of collegues.
>> Mainly it concerns the possibility to extend composition with boolean
>> operators (ex.: A field is either in the range 1-10 OR 20-30 AND
>> notNull) and allow validation of sets of interdependent properties
>> (ex.: EITHER the name field is notNull OR the surname field is notNull/
>> AT LEAST 1 field must be filled/etc).
>>
>> A description of the experimental framework we implemented can be found
>> here http://www.ii.uib.no/publikasjoner/texrap/pdf/2009-389.pdf , and
>> some further discussion on the choices we made here
>> http://www.ii.uib.no/~federico/papers/Annotations.pdf.
>>
>> I hope this might be of some interest for the Hybernate Validator
>> project,
>> but, even if not, it would be nice to get some feedback.
>>
>> Thanks,
>> Federico Mancini
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] On possible extensions for the validator
Hi and thank you for your answer.
I am aware that our work is extremely similar to the jsr 303,
and that is exactly why I wanted to show it to you.
It just happened that we independently developed similar solutions for
the same problem, but
when we saw the specs for the jsr 303, we realized that it would not
make sense to continue
since a much better version of the same thing was already up and going
in Hibernate.
However we have spent a good amount of time and effort on our validator,
and it would be great if some of our ideas could be
picked up by the Hibernate Validator rather than just watch them go to
waste.
Therefore I am very happy that you find some of it of interest, and of
course
I would like to get involved and contribute as I can.
Unfortunatly I am not familiar with the Hibernate Validator code (I only
read the jsr specs) or
how you guys work, so I would not
know where to start, but if you give my some time (I am also working on
some other project right now) and guidelines I will be
happy to help.
Thanks again for the reply,
Federico
Den 05.10.2010 15:17, skrev Hardy Ferentschik:
> Hi Frederico,
>
> sorry for the late reply. I finally had some time to read through your
> paper.
> I think there are strong similarities between you work and Hibernate
> Validator or
> more specific the Bean Validation specification (JSR 303).
>
> Property validation in the SHIP Validator is basically the same as in
> Bean Validation.
> And what you call cross-annotations would be a class level validator
> in Bean Validation terms.
>
> Bean Validation also offers constraint composition similar to what is
> described in your paper.
> What Bean Validation does not offer is a boolean composition of the
> constraints. Here conjunction of
> constraints is always assumed.
>
> We are not able to do something like this:
>
>
> @BoolTest(BoolType.OR)
> @Null
> @Max(10)
> @Target({ METHOD, FIELD })
> @Retention(RUNTIME)
> @Constraint(validatedBy = { })
> public @interface NullOrMax {
>public abstract String message() default "foo";
>public abstract Class[] groups() default { };
>public abstract Class[] payload() default { };
>@OverridesAttribute(constraint = Max.class, name = "value")
>public abstract long max()
> }
>
> Also the ability to validate a subset of all properties from within a
> class level validator sounds interesting.
>
> We could implement these features as Hibernate Validator specific
> extensions.
> Are you interested in getting involved?
>
>
> --Hardy
>
>
> On Tue, 05 Oct 2010 09:48:15 +0200, Federico Mancini
> wrote:
>
>> Hi again,
>> I was just wondering whether I should interpret the lack of answers as
>> "no, this is not interesting at all", or as "we have a lot of other
>> things to do and do not have time for this right now"?
>>
>> Federico
>>
>> Den 22.09.2010 09:08, skrev Federico Mancini:
>>>Hi all,
>>> I am new to the list and I am opening this thread on Emmanuel Bernard's
>>> suggestion, in order to
>>> discuss some possible extensions to the validator (jsr 303) I have been
>>> working on with a couple of collegues.
>>> Mainly it concerns the possibility to extend composition with boolean
>>> operators (ex.: A field is either in the range 1-10 OR 20-30 AND
>>> notNull) and allow validation of sets of interdependent properties
>>> (ex.: EITHER the name field is notNull OR the surname field is notNull/
>>> AT LEAST 1 field must be filled/etc).
>>>
>>> A description of the experimental framework we implemented can be found
>>> here http://www.ii.uib.no/publikasjoner/texrap/pdf/2009-389.pdf , and
>>> some further discussion on the choices we made here
>>> http://www.ii.uib.no/~federico/papers/Annotations.pdf.
>>>
>>> I hope this might be of some interest for the Hybernate Validator
>>> project,
>>> but, even if not, it would be nice to get some feedback.
>>>
>>> Thanks,
>>> Federico Mancini
>>> ___
>>> hibernate-dev mailing list
>>> hibernate-dev@lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Fail fast feature for Hibernate Validator
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
2010/10/4 Emmanuel Bernard
> Ive been toying with the number idea while talking with Max.
> Im not sure what use case that solves provided the highly unpredictable
> nature of what's get returned.
>
> It might be more useful and get a usecase if we spec what gets returned
> roughly. Like deep-last algorithm etc.
>
>
>
> On 4 oct. 2010, at 22:17, Gunnar Morling
> wrote:
>
> Hi,
>
> I like the idea. Emmanuel's performance test showed an execution time per
> validation of 11 vs. 74 ms on my system, so there seems to be some
> potential. Instead of having a "failFast" flag one could also introduce a
> numeric parameter to control, when validation should stop. A value of "1"
> would be equal to the flag being true, but one could also decide to stop
> just after 3 validation errors for instance.
>
> Gunnar
>
>
> 2010/10/4 Emmanuel Bernard <
> emman...@hibernate.org>
>
>> That or slowish validations.
>>
>> One typical use case is that:
>>
>> if ( validator.validate(customer, StraightToValidationScreen.class).size()
>> >0 ) {
>> //manual process
>> }
>> else {
>> //automatic process
>> }
>>
>> BTW, I've committed a non scientific perf test that shows an average of 5x
>> perf improvement on an object graph of 5 object (one master and 4 children)
>> and 4 constraints on A and 3 on B. Around 22ms vs 120 ms. (log4j logs set to
>> ERROR). The perf change is visible even on smallish graphs.
>>
>> It can be worthwhile.
>>
>> On 4 oct. 2010, at 16:20, Hardy Ferentschik wrote:
>>
>> > What would be the usecase? Saving time in large object graphs where I am
>> only interested in whether there is a
>> > failure at all? You really need LARGE object graphs to make this worth
>> while.
>> >
>> >
>> > On Mon, 04 Oct 2010 15:45:34 +0200, Emmanuel Bernard
>> > <
>> emman...@hibernate.org> wrote:
>> >
>> >>
>>
>> http://github.com/emmanuelbernard/hibernate-validator/commits/failFast
>> >>
>> >> What do you guys think?
>> >>
>> >> The idea is to stop a the first failure.
>> >> You can enable that :
>> >> - by property
>> >> - at config time
>> >> - when the Validator is created
>> >>
>> >> Look at
>> >>
>>
>> http://github.com/emmanuelbernard/hibernate-validator/blob/failFast/hibernate-validator/src/test/java/org/hibernate/validator/test/engine/failFast/FailFastTest.java
>> >> for code examples.
>> >>
>> >> Emmanuel
>> >>
>> >
>>
>>
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>>
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] On possible extensions for the validator
Hi,
Help and contributions are always welcome :)
I recommend you start with this page
http://community.jboss.org/wiki/ContributingtoHibernateValidator
It contains information on where and how to check out the source and how
to built the project.
Once you have a local checkout and made yourself a little familiar with
the code you can
always ask more concrete questions either on this mailing list or on the
IRC channel #hibernate-dev on
irc.freenode.net.
We would also create an issue for the feature you want to implement on the
Validator Jira -
http://opensource.atlassian.com/projects/hibernate/browse/HV
Hope this helps for now.
--Hardy
On Tue, 05 Oct 2010 15:49:06 +0200, Federico Mancini
wrote:
> Hi and thank you for your answer.
>
> I am aware that our work is extremely similar to the jsr 303,
> and that is exactly why I wanted to show it to you.
> It just happened that we independently developed similar solutions for
> the same problem, but
> when we saw the specs for the jsr 303, we realized that it would not
> make sense to continue
> since a much better version of the same thing was already up and going
> in Hibernate.
>
> However we have spent a good amount of time and effort on our validator,
> and it would be great if some of our ideas could be
> picked up by the Hibernate Validator rather than just watch them go to
> waste.
>
> Therefore I am very happy that you find some of it of interest, and of
> course
> I would like to get involved and contribute as I can.
>
> Unfortunatly I am not familiar with the Hibernate Validator code (I only
> read the jsr specs) or
> how you guys work, so I would not
> know where to start, but if you give my some time (I am also working on
> some other project right now) and guidelines I will be
> happy to help.
>
> Thanks again for the reply,
> Federico
>
> Den 05.10.2010 15:17, skrev Hardy Ferentschik:
>> Hi Frederico,
>>
>> sorry for the late reply. I finally had some time to read through your
>> paper.
>> I think there are strong similarities between you work and Hibernate
>> Validator or
>> more specific the Bean Validation specification (JSR 303).
>>
>> Property validation in the SHIP Validator is basically the same as in
>> Bean Validation.
>> And what you call cross-annotations would be a class level validator in
>> Bean Validation terms.
>>
>> Bean Validation also offers constraint composition similar to what is
>> described in your paper.
>> What Bean Validation does not offer is a boolean composition of the
>> constraints. Here conjunction of
>> constraints is always assumed.
>>
>> We are not able to do something like this:
>>
>>
>> @BoolTest(BoolType.OR)
>> @Null
>> @Max(10)
>> @Target({ METHOD, FIELD })
>> @Retention(RUNTIME)
>> @Constraint(validatedBy = { })
>> public @interface NullOrMax {
>>public abstract String message() default "foo";
>>public abstract Class[] groups() default { };
>>public abstract Class[] payload() default { };
>>@OverridesAttribute(constraint = Max.class, name = "value")
>>public abstract long max()
>> }
>>
>> Also the ability to validate a subset of all properties from within a
>> class level validator sounds interesting.
>>
>> We could implement these features as Hibernate Validator specific
>> extensions.
>> Are you interested in getting involved?
>>
>>
>> --Hardy
>>
>>
>> On Tue, 05 Oct 2010 09:48:15 +0200, Federico Mancini
>> wrote:
>>
>>> Hi again,
>>> I was just wondering whether I should interpret the lack of answers as
>>> "no, this is not interesting at all", or as "we have a lot of other
>>> things to do and do not have time for this right now"?
>>>
>>> Federico
>>>
>>> Den 22.09.2010 09:08, skrev Federico Mancini:
Hi all,
I am new to the list and I am opening this thread on Emmanuel
Bernard's
suggestion, in order to
discuss some possible extensions to the validator (jsr 303) I have
been
working on with a couple of collegues.
Mainly it concerns the possibility to extend composition with boolean
operators (ex.: A field is either in the range 1-10 OR 20-30 AND
notNull) and allow validation of sets of interdependent properties
(ex.: EITHER the name field is notNull OR the surname field is
notNull/
AT LEAST 1 field must be filled/etc).
A description of the experimental framework we implemented can be
found
here http://www.ii.uib.no/publikasjoner/texrap/pdf/2009-389.pdf , and
some further discussion on the choices we made here
http://www.ii.uib.no/~federico/papers/Annotations.pdf.
I hope this might be of some interest for the Hybernate Validator
project,
but, even if not, it would be nice to get some feedback.
Thanks,
Federico Mancini
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/h
Re: [hibernate-dev] Fail fast feature for Hibernate Validator
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
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
>
>
> 2010/10/4 Emmanuel Bernard
>
>> Ive been toying with the number idea while talking with Max.
>> Im not sure what use case that solves provided the highly unpredictable
>> nature of what's get returned.
>>
>> It might be more useful and get a usecase if we spec what gets returned
>> roughly. Like deep-last algorithm etc.
>>
>>
>>
>> On 4 oct. 2010, at 22:17, Gunnar Morling
>> wrote:
>>
>> Hi,
>>
>> I like the idea. Emmanuel's performance test showed an execution time
>> per
>> validation of 11 vs. 74 ms on my system, so there seems to be some
>> potential. Instead of having a "failFast" flag one could also introduce
>> a
>> numeric parameter to control, when validation should stop. A value of
>> "1"
>> would be equal to the flag being true, but one could also decide to stop
>> just after 3 validation errors for instance.
>>
>> Gunnar
>>
>>
>> 2010/10/4 Emmanuel Bernard <
>> emman...@hibernate.org>
>>
>>> That or slowish validations.
>>>
>>> One typical use case is that:
>>>
>>> if ( validator.validate(customer,
>>> StraightToValidationScreen.class).size()
>>> >0 ) {
>>> //manual process
>>> }
>>> else {
>>> //automatic process
>>> }
>>>
>>> BTW, I've committed a non scientific perf test that shows an average
>>> of 5x
>>> perf improvement on an object graph of 5 object (one master and 4
>>> children)
>>> and 4 constraints on A and 3 on B. Around 22ms vs 120 ms. (log4j logs
>>> set to
>>> ERROR). The perf change is visible even on smallish graphs.
>>>
>>> It can be worthwhile.
>>>
>>> On 4 oct. 2010, at 16:20, Hardy Ferentschik wrote:
>>>
>>> > What would be the usecase? Saving time in large object graphs where
>>> I am
>>> only interested in whether there is a
>>> > failure at all? You really need LARGE object graphs to make this
>>> worth
>>> while.
>>> >
>>> >
>>> > On Mon, 04 Oct 2010 15:45:34 +0200, Emmanuel Bernard
>>> <
>>> emman...@hibernate.org> wrote:
>>> >
>>> >>
>>>
>>> http://github.com/emmanuelbernard/hibernate-validator/commits/failFast
>>> >>
>>> >> What do you guys think?
>>> >>
>>> >> The idea is to stop a the first failure.
>>> >> You can enable that :
>>> >> - by property
>>> >> - at config time
>>> >> - when the Validator is created
>>> >>
>>> >> Look at
>>> >>
>>>
>>> http://github.com/emmanuelbernard/hibernate-validator/blob/failFast/hibernate-validator/src/test/java/org/hibernate/validator/test/engine/failFast/FailFastTest.java
>>> >> for code examples.
>>> >>
>>> >> Emmanuel
>>> >>
>>> >
>>>
>>>
>>> ___
>>> hibernate-dev mailing list
>>> hibernate-dev@lists.jboss.org
>>>
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>
>>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Fail fast feature for Hibernate Validator
public doStuff(@Param("name") String name, @Param("command") Object command) {
...
}
On 5 oct. 2010, at 16:07, Hardy Ferentschik wrote:
> 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
> 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
>>
>>
>> 2010/10/4 Emmanuel Bernard
>>
>>> Ive been toying with the number idea while talking with Max.
>>> Im not sure what use case that solves provided the highly unpredictable
>>> nature of what's get returned.
>>>
>>> It might be more useful and get a usecase if we spec what gets returned
>>> roughly. Like deep-last algorithm etc.
>>>
>>>
>>>
>>> On 4 oct. 2010, at 22:17, Gunnar Morling
>>> wrote:
>>>
>>> Hi,
>>>
>>> I like the idea. Emmanuel's performance test showed an execution time per
>>> validation of 11 vs. 74 ms on my system, so there seems to be some
>>> potential. Instead of having a "failFast" flag one could also introduce a
>>> numeric parameter to control, when validation should stop. A value of "1"
>>> would be equal to the flag being true, but one could also decide to stop
>>> just after 3 validation errors for instance.
>>>
>>> Gunnar
>>>
>>>
>>> 2010/10/4 Emmanuel Bernard <
>>> emman...@hibernate.org>
>>>
That or slowish validations.
One typical use case is that:
if ( validator.validate(customer, StraightToValidationScreen.class).size()
>0 ) {
//manual process
}
else {
//automatic process
}
BTW, I've committed a non scientific perf test that shows an average of 5x
perf improvement on an object graph of 5 object (one master and 4 children)
and 4 constraints on A and 3 on B. Around 22ms vs 120 ms. (log4j logs set
to
ERROR). The perf change is visible even on smallish graphs.
It can be worthwhile.
On 4 oct. 2010, at 16:20, Hardy Ferentschik wrote:
> What would be the usecase? Saving time in large object graphs where I am
only interested in whether there is a
> failure at all? You really need LARGE object graphs to make this worth
while.
>
>
> On Mon, 04 Oct 2010 15:45:34 +0200, Emmanuel Bernard
> <
emman...@hibernate.org> wrote:
>
>>
http://github.com/emmanuelbernard/hibernate-validator/commits/failFast
>>
>> What do you guys think?
>>
>> The idea is to stop a the first failure.
>> You can enable that :
>> - by property
>> - at config time
>> - when the Validator is created
>>
>> Look at
>>
http://github.com/emmanuelbernard/hibernate-validator/blob/failFast/hibernate-validator/src/test/java/org/hibernate/validator/test/engine/failFast/FailFastTest.java
>> for code examples.
>>
>> Emmanuel
>>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Fail fast feature for Hibernate Validator
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
> 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
>>
>>
>> 2010/10/4 Emmanuel Bernard
>>
>> Ive been toying with the number idea while talking with Max.
>>> Im not sure what use case that solves provided the highly unpredictable
>>> nature of what's get returned.
>>>
>>> It might be more useful and get a usecase if we spec what gets returned
>>> roughly. Like deep-last algorithm etc.
>>>
>>>
>>>
>>> On 4 oct. 2010, at 22:17, Gunnar Morling
>>> wrote:
>>>
>>> Hi,
>>>
>>> I like the idea. Emmanuel's performance test showed an execution time per
>>> validation of 11 vs. 74 ms on my system, so there seems to be some
>>> potential. Instead of having a "failFast" flag one could also introduce a
>>> numeric parameter to control, when validation should stop. A value of "1"
>>> would be equal to the flag being true, but one could also decide to stop
>>> just after 3 validation errors for instance.
>>>
>>> Gunnar
>>>
>>>
>>> 2010/10/4 Emmanuel Bernard <
>>> emman...@hibernate.org>
>>>
>>> That or slowish validations.
One typical use case is that:
if ( validator.validate(customer,
StraightToValidationScreen.class).size()
>0 ) {
//manual process
}
else {
//automatic process
}
BTW, I've committed a non scientific perf test that shows an average of
5x
perf improvement on an object graph of 5 object (one master and 4
children)
and 4 constraints on A and 3 on B. Around 22ms vs 120 ms. (log4j logs
set to
ERROR). The perf change is visible even on smallish graphs.
It can be worthwhile.
On 4 oct. 2010, at 16:20, Hardy Ferentschik wrote:
> What would be the usecase? Saving time in large object graphs where I
am
only interested in whether there is a
> failure at all? You really need LARGE object graphs to make this worth
while.
>
>
> On Mon, 04 Oct 2010 15:45:34 +0200, Emmanuel Bernard <<
emman...@hibernate.org>
emman...@hibernate.org> wrote:
>
>>
http://github.com/emmanuelbernard/hibernate-validator/commits/failFast
>>
>> What do you guys think?
>>
>> The idea is to stop a the first failure.
>> You can enable that :
>> - by property
>> - at config time
>> - when the Validator is created
>>
>> Look at
>>
<
http://github.com/emmanuelbernard/hibernate-validator/blob/failFast/hibernate-validator/src/test/java/org/hibernate/validator/test/engine/failFast/FailFastTest.java
>
http://github.com/emmanuelbernard/hibernate-validator/blob/failFast/hibernate-validator/src/test/java/org/hibernate/validator/test/engine/failFast/FailFastTest.java
>> for code examples.
>>
>> Emmanuel
>>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Fail fast feature for Hibernate Validator
If we /really/ want stopAfterNFailures, I'd go straight to it. It's easy to
implement and will confuse people less. But the number of failures will be a
guaranteed to be above int (if there are enough ;) ) and the order will be
unspecified though today we do breadth-first I believe which is what most
people will want.
I am still not 100% foreseeing why a UI would want 5 errors at most :)
Max, want to weight in?
On 5 oct. 2010, at 15:54, Gunnar Morling 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
>
>
> 2010/10/4 Emmanuel Bernard
> Ive been toying with the number idea while talking with Max.
> Im not sure what use case that solves provided the highly unpredictable
> nature of what's get returned.
>
> It might be more useful and get a usecase if we spec what gets returned
> roughly. Like deep-last algorithm etc.
>
>
>
> On 4 oct. 2010, at 22:17, Gunnar Morling
> wrote:
>
>> Hi,
>>
>> I like the idea. Emmanuel's performance test showed an execution time per
>> validation of 11 vs. 74 ms on my system, so there seems to be some
>> potential. Instead of having a "failFast" flag one could also introduce a
>> numeric parameter to control, when validation should stop. A value of "1"
>> would be equal to the flag being true, but one could also decide to stop
>> just after 3 validation errors for instance.
>>
>> Gunnar
>>
>>
>> 2010/10/4 Emmanuel Bernard
>> That or slowish validations.
>>
>> One typical use case is that:
>>
>> if ( validator.validate(customer, StraightToValidationScreen.class).size()
>> >0 ) {
>> //manual process
>> }
>> else {
>> //automatic process
>> }
>>
>> BTW, I've committed a non scientific perf test that shows an average of 5x
>> perf improvement on an object graph of 5 object (one master and 4 children)
>> and 4 constraints on A and 3 on B. Around 22ms vs 120 ms. (log4j logs set to
>> ERROR). The perf change is visible even on smallish graphs.
>>
>> It can be worthwhile.
>>
>> On 4 oct. 2010, at 16:20, Hardy Ferentschik wrote:
>>
>> > What would be the usecase? Saving time in large object graphs where I am
>> > only interested in whether there is a
>> > failure at all? You really need LARGE object graphs to make this worth
>> > while.
>> >
>> >
>> > On Mon, 04 Oct 2010 15:45:34 +0200, Emmanuel Bernard
>> > wrote:
>> >
>> >> http://github.com/emmanuelbernard/hibernate-validator/commits/failFast
>> >>
>> >> What do you guys think?
>> >>
>> >> The idea is to stop a the first failure.
>> >> You can enable that :
>> >> - by property
>> >> - at config time
>> >> - when the Validator is created
>> >>
>> >> Look at
>> >> http://github.com/emmanuelbernard/hibernate-validator/blob/failFast/hibernate-validator/src/test/java/org/hibernate/validator/test/engine/failFast/FailFastTest.java
>> >> for code examples.
>> >>
>> >> Emmanuel
>> >>
>> >
>>
>>
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Fail fast feature for Hibernate Validator
oops reading Gunnar's answer, I'm probably answer the wrong question :)
On 5 oct. 2010, at 17:23, Emmanuel Bernard wrote:
> public doStuff(@Param("name") String name, @Param("command") Object command) {
>...
> }
>
> On 5 oct. 2010, at 16:07, Hardy Ferentschik wrote:
>
>> 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
>> 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
>>>
>>>
>>> 2010/10/4 Emmanuel Bernard
>>>
Ive been toying with the number idea while talking with Max.
Im not sure what use case that solves provided the highly unpredictable
nature of what's get returned.
It might be more useful and get a usecase if we spec what gets returned
roughly. Like deep-last algorithm etc.
On 4 oct. 2010, at 22:17, Gunnar Morling
wrote:
Hi,
I like the idea. Emmanuel's performance test showed an execution time per
validation of 11 vs. 74 ms on my system, so there seems to be some
potential. Instead of having a "failFast" flag one could also introduce a
numeric parameter to control, when validation should stop. A value of "1"
would be equal to the flag being true, but one could also decide to stop
just after 3 validation errors for instance.
Gunnar
2010/10/4 Emmanuel Bernard <
emman...@hibernate.org>
> That or slowish validations.
>
> One typical use case is that:
>
> if ( validator.validate(customer, StraightToValidationScreen.class).size()
>> 0 ) {
> //manual process
> }
> else {
> //automatic process
> }
>
> BTW, I've committed a non scientific perf test that shows an average of 5x
> perf improvement on an object graph of 5 object (one master and 4
> children)
> and 4 constraints on A and 3 on B. Around 22ms vs 120 ms. (log4j logs set
> to
> ERROR). The perf change is visible even on smallish graphs.
>
> It can be worthwhile.
>
> On 4 oct. 2010, at 16:20, Hardy Ferentschik wrote:
>
>> What would be the usecase? Saving time in large object graphs where I am
> only interested in whether there is a
>> failure at all? You really need LARGE object graphs to make this worth
> while.
>>
>>
>> On Mon, 04 Oct 2010 15:45:34 +0200, Emmanuel Bernard
>> <
> emman...@hibernate.org> wrote:
>>
>>>
>
> http://github.com/emmanuelbernard/hibernate-validator/commits/failFast
>>>
>>> What do you guys think?
>>>
>>> The idea is to stop a the first failure.
>>> You can enable that :
>>> - by property
>>> - at config time
>>> - when the Validator is created
>>>
>>> Look at
>>>
>
> http://github.com/emmanuelbernard/hibernate-validator/blob/failFast/hibernate-validator/src/test/java/org/hibernate/validator/test/engine/failFast/FailFastTest.java
>>> for code examples.
>>>
>>> Emmanuel
>>>
>>
>
>
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
>
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>>
>
>
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Fail fast feature for Hibernate Validator
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 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 > >> 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
Re: [hibernate-dev] Fail fast feature for Hibernate Validator
I was about to ask what you've been smoking ;-)
On Tue, 05 Oct 2010 17:45:23 +0200, Emmanuel Bernard
wrote:
> oops reading Gunnar's answer, I'm probably answer the wrong question :)
>
> On 5 oct. 2010, at 17:23, Emmanuel Bernard wrote:
>
>> public doStuff(@Param("name") String name, @Param("command") Object
>> command) {
>>...
>> }
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Fail fast feature for Hibernate Validator
2010/10/5 Hardy Ferentschik :
> I was about to ask what you've been smoking ;-)
ROFL, It's always a lot of fun to follow this list :)
Cheers,
Sanne
>
> On Tue, 05 Oct 2010 17:45:23 +0200, Emmanuel Bernard
> wrote:
>
>> oops reading Gunnar's answer, I'm probably answer the wrong question :)
>>
>> On 5 oct. 2010, at 17:23, Emmanuel Bernard wrote:
>>
>>> public doStuff(@Param("name") String name, @Param("command") Object
>>> command) {
>>> ...
>>> }
>
>
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
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 > 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 >> >>> 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
Re: [hibernate-dev] Fail fast feature for Hibernate Validator
Hi,
answers inline.
Gunnar
2010/10/5 Emmanuel Bernard
> 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 > {
}
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.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
> >>
> >>> 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
Re: [hibernate-dev] Fail fast feature for Hibernate Validator
On Oct 5, 2010, at 17:43, Emmanuel Bernard wrote:
> If we /really/ want stopAfterNFailures, I'd go straight to it. It's easy to
> implement and will confuse people less. But the number of failures will be a
> guaranteed to be above int (if there are enough ;) ) and the order will be
> unspecified though today we do breadth-first I believe which is what most
> people will want.
>
> I am still not 100% foreseeing why a UI would want 5 errors at most :)
>
> Max, want to weight in?
the intent was really just that only showing the *first* failure would
introduce an annoying "enter data, submit, 1 error, fix that 1 error, submit, 1
new error, fix that 1 error, submit, ...0 errors"-cycle; thus saying "get at
most 5 errors" would reduce that cycle but again if you are waiting for a
response waiting those few msecs are probably fine.
/max
>
> On 5 oct. 2010, at 15:54, Gunnar Morling 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
>>
>>
>> 2010/10/4 Emmanuel Bernard
>> Ive been toying with the number idea while talking with Max.
>> Im not sure what use case that solves provided the highly unpredictable
>> nature of what's get returned.
>>
>> It might be more useful and get a usecase if we spec what gets returned
>> roughly. Like deep-last algorithm etc.
>>
>>
>>
>> On 4 oct. 2010, at 22:17, Gunnar Morling
>> wrote:
>>
>>> Hi,
>>>
>>> I like the idea. Emmanuel's performance test showed an execution time per
>>> validation of 11 vs. 74 ms on my system, so there seems to be some
>>> potential. Instead of having a "failFast" flag one could also introduce a
>>> numeric parameter to control, when validation should stop. A value of "1"
>>> would be equal to the flag being true, but one could also decide to stop
>>> just after 3 validation errors for instance.
>>>
>>> Gunnar
>>>
>>>
>>> 2010/10/4 Emmanuel Bernard
>>> That or slowish validations.
>>>
>>> One typical use case is that:
>>>
>>> if ( validator.validate(customer, StraightToValidationScreen.class).size()
>>> >0 ) {
>>> //manual process
>>> }
>>> else {
>>> //automatic process
>>> }
>>>
>>> BTW, I've committed a non scientific perf test that shows an average of 5x
>>> perf improvement on an object graph of 5 object (one master and 4 children)
>>> and 4 constraints on A and 3 on B. Around 22ms vs 120 ms. (log4j logs set
>>> to ERROR). The perf change is visible even on smallish graphs.
>>>
>>> It can be worthwhile.
>>>
>>> On 4 oct. 2010, at 16:20, Hardy Ferentschik wrote:
>>>
>>> > What would be the usecase? Saving time in large object graphs where I am
>>> > only interested in whether there is a
>>> > failure at all? You really need LARGE object graphs to make this worth
>>> > while.
>>> >
>>> >
>>> > On Mon, 04 Oct 2010 15:45:34 +0200, Emmanuel Bernard
>>> > wrote:
>>> >
>>> >> http://github.com/emmanuelbernard/hibernate-validator/commits/failFast
>>> >>
>>> >> What do you guys think?
>>> >>
>>> >> The idea is to stop a the first failure.
>>> >> You can enable that :
>>> >> - by property
>>> >> - at config time
>>> >> - when the Validator is created
>>> >>
>>> >> Look at
>>> >> http://github.com/emmanuelbernard/hibernate-validator/blob/failFast/hibernate-validator/src/test/java/org/hibernate/validator/test/engine/failFast/FailFastTest.java
>>> >> for code examples.
>>> >>
>>> >> Emmanuel
>>> >>
>>> >
>>>
>>>
>>> ___
>>> hibernate-dev mailing list
>>> hibernate-dev@lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
