12:03 p.m.
Hi,
The first Alpha of the Bean Validation 2.0 reference implementation,
Hibernate Validator 6, is available now.
It implements the Early Draft 1, but also contains some more things
where we thought it'd be great to get some feedback first. E.g.
there's support for constraint definition using Lambda expressions.
Please check out the post on beanvalidation.org and the full
announcement on the Hibernate blog for all the details:
*
http://beanvalidation.org/news/2017/02/16/first-alpha-of-bean-validation-...
* http://in.relation.to/2017/02/16/hibernate-validator-600-alpha1-out/
This release gives you the opportunity to play with the things we've
added so far, for instance you can experiment with custom value
extractors. Any feedback is welcome.
Thanks a lot to Guillaume for his hard work on this release!
--Gunnar
12:29 p.m.
Hi Gunnar,
Since Duration is really just seconds and milliseconds and any conversion
is always flat (in the sense it doesn't take into account daylight savings
time, for instance), I find it way less useful to support than Period and
arbitrary TemporalAmounts (such as
http://www.threeten.org/threeten-extra/apidocs/org/threeten/extra/Days.html
).
That's something we should probably focus on more because they are even
more fitting for use in business applications. Hopefully I won't disappear
for weeks anymore ;-)
Regards,
Michael
On Thu, Feb 16, 2017 at 4:03 PM, Gunnar Morling <gunnar(a)hibernate.org>
wrote:
Hi,
The first Alpha of the Bean Validation 2.0 reference implementation,
Hibernate Validator 6, is available now.
It implements the Early Draft 1, but also contains some more things
where we thought it'd be great to get some feedback first. E.g.
there's support for constraint definition using Lambda expressions.
Please check out the post on beanvalidation.org and the full
announcement on the Hibernate blog for all the details:
* http://beanvalidation.org/news/2017/02/16/first-alpha-
of-bean-validation-2-0-reference-implementation/
* http://in.relation.to/2017/02/16/hibernate-validator-600-alpha1-out/
This release gives you the opportunity to play with the things we've
added so far, for instance you can experiment with custom value
extractors. Any feedback is welcome.
Thanks a lot to Guillaume for his hard work on this release!
--Gunnar
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
12:48 p.m.
Hi Michael,
On Thu, Feb 16, 2017 at 7:29 PM, Michael Nascimento <misterm(a)gmail.com>
wrote:
Since Duration is really just seconds and milliseconds and any conversion
is always flat (in the sense it doesn't take into account daylight savings
time, for instance), I find it way less useful to support than Period and
arbitrary TemporalAmounts (such as http://www.threeten.org/
threeten-extra/apidocs/org/threeten/extra/Days.html ).
The first PR of Marko contained the Period support. The issue is that
Period is not comparable and there is no easy way to compare 2 periods so
we decided to not implement it for now. The typical issue we had is how do
you compare 1 month and 30 days.
As for supporting threeten-extra, it wouldn't be done in the spec anyway.
But we are open to consider it for HV (as we did for Joda a long time ago).
PR welcome!
--
Guillaume
1:17 p.m.
On Thu, Feb 16, 2017 at 4:48 PM, Guillaume Smet <guillaume.smet(a)gmail.com>
wrote:
Hi Michael,
On Thu, Feb 16, 2017 at 7:29 PM, Michael Nascimento <misterm(a)gmail.com>
wrote:
>
> Since Duration is really just seconds and milliseconds and any conversion
> is always flat (in the sense it doesn't take into account daylight savings
> time, for instance), I find it way less useful to support than Period and
> arbitrary TemporalAmounts (such as http://www.threeten.org/thr
> eeten-extra/apidocs/org/threeten/extra/Days.html ).
>
The first PR of Marko contained the Period support. The issue is that
Period is not comparable and there is no easy way to compare 2 periods so
we decided to not implement it for now. The typical issue we had is how do
you compare 1 month and 30 days.
You don't compare, because they are not the same. The idea is that the
Period must be defined in terms of the units for which you defined its
boundaries.
As for supporting threeten-extra, it wouldn't be done in the spec
anyway.
You shouldn't support threeten-extra, but rather arbitrary TemporalAmounts.
Then threeten-extra just happen to be one of those. There must be something
like @ChronoUnitMax/@ChronoUnitMin such as:
@ChronoUnitMax(unit=DAYS, value=1)
As I said, I'm open to provide input, I was just surprised this support was
not discussed as part of the spec itself and prototyping work started right
way (in the less useful class for business applications, in my opinion).
Regards,
Michael
2:11 a.m.
2017-02-16 20:17 GMT+01:00 Michael Nascimento <misterm(a)gmail.com>:
On Thu, Feb 16, 2017 at 4:48 PM, Guillaume Smet
<guillaume.smet(a)gmail.com>
wrote:
>
> Hi Michael,
>
> On Thu, Feb 16, 2017 at 7:29 PM, Michael Nascimento <misterm(a)gmail.com>
> wrote:
>>
>> Since Duration is really just seconds and milliseconds and any conversion
>> is always flat (in the sense it doesn't take into account daylight savings
>> time, for instance), I find it way less useful to support than Period and
>> arbitrary TemporalAmounts (such as
>> http://www.threeten.org/threeten-extra/apidocs/org/threeten/extra/Days.html
>> ).
>
>
> The first PR of Marko contained the Period support. The issue is that
> Period is not comparable and there is no easy way to compare 2 periods so we
> decided to not implement it for now. The typical issue we had is how do you
> compare 1 month and 30 days.
You don't compare, because they are not the same. The idea is that the
Period must be defined in terms of the units for which you defined its
boundaries.
I see. I'm wondering though how practical that will be. Will the
developer who puts the constraint always know the structure of the
Period set to the field (data set by the application user)?
>
> As for supporting threeten-extra, it wouldn't be done in the spec anyway.
You shouldn't support threeten-extra, but rather arbitrary TemporalAmounts.
Then threeten-extra just happen to be one of those. There must be something
like @ChronoUnitMax/@ChronoUnitMin such as:
@ChronoUnitMax(unit=DAYS, value=1)
How would that look like for a Period with several elements set, e.g.
"3 months, 2 days"? Would we need a dedicated member in @ChronoUnitMax
for each value of ChronoUnit (which are a lot)?
As I said, I'm open to provide input, I was just surprised this support was
not discussed as part of the spec itself and prototyping work started right
way (in the less useful class for business applications, in my opinion).
We had a discussion of Duration et al. a while ago, but it petered
out. So we thought we'd add something to the RI to spark a new
discussion. Seems it worked :)
Regards,
Michael
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
1:13 p.m.
On Fri, Feb 17, 2017 at 5:11 AM, Gunnar Morling <gunnar(a)hibernate.org>
wrote:
> You don't compare, because they are not the same. The idea
is that the
> Period must be defined in terms of the units for which you defined its
> boundaries.
I see. I'm wondering though how practical that will be. Will the
developer who puts the constraint always know the structure of the
Period set to the field (data set by the application user)?
In the case you want it to be validated, you ought to :-)
> You shouldn't support threeten-extra, but rather arbitrary
TemporalAmounts.
> Then threeten-extra just happen to be one of those. There must be
something
> like @ChronoUnitMax/@ChronoUnitMin such as:
>
> @ChronoUnitMax(unit=DAYS, value=1)
How would that look like for a Period with several elements set, e.g.
"3 months, 2 days"? Would we need a dedicated member in @ChronoUnitMax
for each value of ChronoUnit (which are a lot)?
What do you mean by a member in @ChronoUnitMax? In my example, I suggest
using unit as a member, leading to unit and value being the only members.
We had a discussion of Duration et al. a while ago, but it petered
out. So we thought we'd add something to the RI to spark a new
discussion. Seems it worked :)
Can´t disagree :-)
Regards,
Michael
1:51 a.m.
2017-02-20 20:13 GMT+01:00 Michael Nascimento <misterm(a)gmail.com>:
On Fri, Feb 17, 2017 at 5:11 AM, Gunnar Morling
<gunnar(a)hibernate.org>
wrote:
>
> > You don't compare, because they are not the same. The idea is that the
> > Period must be defined in terms of the units for which you defined its
> > boundaries.
>
> I see. I'm wondering though how practical that will be. Will the
> developer who puts the constraint always know the structure of the
> Period set to the field (data set by the application user)?
In the case you want it to be validated, you ought to :-)
But that's the problem, can you really?
The actual field values are set at application runtime, e.g. entered
by a user sitting in front of the application. So the application
developer would have to "lock down" whatever can be put in to match
the unit set in the constraint. It's doable but I'm having doubts that
this constraint pulls its eight eventually.
>
>
> > You shouldn't support threeten-extra, but rather arbitrary
> > TemporalAmounts.
> > Then threeten-extra just happen to be one of those. There must be
> > something
> > like @ChronoUnitMax/@ChronoUnitMin such as:
> >
> > @ChronoUnitMax(unit=DAYS, value=1)
>
> How would that look like for a Period with several elements set, e.g.
> "3 months, 2 days"? Would we need a dedicated member in @ChronoUnitMax
> for each value of ChronoUnit (which are a lot)?
What do you mean by a member in @ChronoUnitMax? In my example, I suggest
using unit as a member, leading to unit and value being the only members.
By member I meant months(), days(), hours() etc. In the "one unit, one
value" model, how would you express "max 3 month and two weeks"? We
could exclude such case of course, it may sufficiently well be
expressed as "max 10 weeks".
>
> We had a discussion of Duration et al. a while ago, but it petered
> out. So we thought we'd add something to the RI to spark a new
> discussion. Seems it worked :)
Can´t disagree :-)
Regards,
Michael
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
4:34 p.m.
Michael I see the business case for the Period validation, but the
complexity (impossibility) of a reliable comparison between Periods it
seems widespread and accepted between the developers. Personally I don't
see the benefits to have it in the spec if it risks to generate confusion
or errors.
If you have some inputs, these are welcome. Could you enrich your previous
example (years, month, days)?
Thanks
On Tue, Feb 21, 2017 at 8:51 AM, Gunnar Morling <gunnar(a)hibernate.org>
wrote:
2017-02-20 20:13 GMT+01:00 Michael Nascimento
<misterm(a)gmail.com>:
> On Fri, Feb 17, 2017 at 5:11 AM, Gunnar Morling <gunnar(a)hibernate.org>
> wrote:
>>
>> > You don't compare, because they are not the same. The idea is that the
>> > Period must be defined in terms of the units for which you defined its
>> > boundaries.
>>
>> I see. I'm wondering though how practical that will be. Will the
>> developer who puts the constraint always know the structure of the
>> Period set to the field (data set by the application user)?
>
>
> In the case you want it to be validated, you ought to :-)
But that's the problem, can you really?
The actual field values are set at application runtime, e.g. entered
by a user sitting in front of the application. So the application
developer would have to "lock down" whatever can be put in to match
the unit set in the constraint. It's doable but I'm having doubts that
this constraint pulls its eight eventually.
>
>>
>>
>> > You shouldn't support threeten-extra, but rather arbitrary
>> > TemporalAmounts.
>> > Then threeten-extra just happen to be one of those. There must be
>> > something
>> > like @ChronoUnitMax/@ChronoUnitMin such as:
>> >
>> > @ChronoUnitMax(unit=DAYS, value=1)
>>
>> How would that look like for a Period with several elements set, e.g.
>> "3 months, 2 days"? Would we need a dedicated member in
@ChronoUnitMax
>> for each value of ChronoUnit (which are a lot)?
>
>
> What do you mean by a member in @ChronoUnitMax? In my example, I suggest
> using unit as a member, leading to unit and value being the only members.
By member I meant months(), days(), hours() etc. In the "one unit, one
value" model, how would you express "max 3 month and two weeks"? We
could exclude such case of course, it may sufficiently well be
expressed as "max 10 weeks".
>
>>
>> We had a discussion of Duration et al. a while ago, but it petered
>> out. So we thought we'd add something to the RI to spark a new
>> discussion. Seems it worked :)
>
>
> Can´t disagree :-)
>
> Regards,
> Michael
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
3009
days inactive
3015
days old
beanvalidation-dev@lists.jboss.org
7 comments
4 participants
participants (4)
-
Guillaume Smet -
Gunnar Morling -
Marco Molteni -
Michael Nascimento