Re: [hibernate-dev] Fail fast feature for Hibernate Validator
by Gunnar Morling
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 <emmanuel(a)hibernate.org>
> 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 <gunnar.morling(a)googlemail.com>
> 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 < <emmanuel(a)hibernate.org>
> emmanuel(a)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 <<emmanuel(a)hibernate.org>
>> emmanuel(a)hibernate.org> wrote:
>> >
>> >>
>> <http://github.com/emmanuelbernard/hibernate-validator/commits/failFast>
>> 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/hiber...>
>> http://github.com/emmanuelbernard/hibernate-validator/blob/failFast/hiber...
>> >> for code examples.
>> >>
>> >> Emmanuel
>> >>
>> >
>>
>>
>> _______________________________________________
>> hibernate-dev mailing list
>> <hibernate-dev(a)lists.jboss.org>hibernate-dev(a)lists.jboss.org
>> <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>
14 years, 2 months
Move of Search to Git
by Emmanuel Bernard
[basically Hardy's email + s/Validator/Search/]
Hi,
Following suite I am planning to move Hibernate Search to git as well.
Given that some of contributors are already
working with Validator branches on GitHub it only makes sense to move the
master to there as well.
I'll be tagging the current state of the svn repo and then disable write
access to the
Validator svn repo.
In case you are having outstanding work against the svn repo and you want
to get this in before the switch
speak up now.
Emmanuel
14 years, 2 months
Move of Validator to git
by Hardy Ferentschik
Hi,
following suite I am planning to move Hibernate Validator to git as well.
Given that some of contributors are already
working with Validator branches on GitHub it only makes sense to move the
master to there as well.
I'll be tagging the current state of the svn repo and then disable write
access to the
Validator svn repo.
In case you are having outstanding work against the svn repo and you want
to get this in before the switch
speak up now.
--Hardy
14 years, 2 months
Transaction API
by Steve Ebersole
Currently there is a big discrepancy between the documentation for some
of the methods on org.hibernate.Transaction and the actual code.
Specifically the methods isActive(), wasRolledBack() and wasCommitted()
explicitly state that they only account for the "local state" of the
transaction object, not the underlying transaction.
However, the code explicitly checks the current status of JTA
transactions to responded to these methods.
We need to fix one or the other. Personally I do not follow the use of
these methods too much, so asking for feedback on which way is more
useful.
--
Steve Ebersole <steve(a)hibernate.org>
http://hibernate.org
14 years, 2 months
SVN tagging
by Steve Ebersole
I am just now tagging SVN for the move to Git. The tag is really just for
posterity sake... Immediately after I will be shutting off write access to the
/core portion of the repo. So please do not commit work to /core from this
moment forward in SVN.
I'll send a follow up when everything is done.
Thanks.
--
Steve Ebersole <steve(a)hibernate.org>
http://hibernate.org
14 years, 2 months
