Re: [bv-dev] BV 2.0 - Add constraints?
by Otávio Gonçalves de Santana
I sent to adopt JSR email list and share it on social media.
https://twitter.com/otaviojava/status/776549007799701504
On 15 Sep 2016 12:00, "Otávio Gonçalves de Santana" <
otaviopolianasantana(a)gmail.com> wrote:
> Nice form!!
> I'm sharing it in adopt JSR program email list.
>
> On 15 Sep 2016 03:46, "Gunnar Morling" <gunnar(a)hibernate.org> wrote:
>
>> Hi,
>>
>> I've created a survey using Google Forms on our blog (staging atm.):
>> http://staging.beanvalidation.org/news/2016/09/15/
>> which-constraints-to-add/
>>
>> Feedback welcome. Unless I hear back otherwise, I'll push it to the
>> production site tomorrow and then let's announce it on Twitter to get some
>> answers. I'd leave it open for two weeks (allowing people to reply after J1
>> which is next week), which should be plenty of time.
>>
>> One question I have is should we allow anonymous voting or require
>> logging in via Google. The latter prevents double votes, but it raises the
>> level for participation and don't think people feel motivated to vote
>> several times on this topic really.
>>
>> Andy thoughts?
>>
>> Thanks,
>>
>> --Gunnar
>>
>>
>> 2016-09-14 12:02 GMT+02:00 Marco Molteni <moltenma(a)gmail.com>:
>>
>>> I agree about @Length. It was listed only because of the frequency. I'd
>>> limit the addition to @NotBlank and @NotEmpty.
>>>
>>> On Wed, Sep 14, 2016 at 11:52 AM, Gunnar Morling <gunnar(a)hibernate.org>
>>> wrote:
>>>
>>>> Btw. I don't see a strong reason for @Length, as we have @Size in the
>>>> spec for it already.
>>>>
>>>> I think it's commonly used in older applications which migrated from HV
>>>> 3.x (proprietary API) to HV 4.x (BV RI) and kept using the legacy
>>>> constraint instead of using the spec'-ed @Size.
>>>>
>>>> 2016-09-14 11:48 GMT+02:00 Gunnar Morling <gunnar(a)hibernate.org>:
>>>>
>>>>> Hi,
>>>>>
>>>>> I like the idea of collecting some more feedback from the community.
>>>>>
>>>>> A blog post may be an option, though I reckon feedback will be sparse
>>>>> based on previous experiences. I'd rather do a survey as it's more
>>>>> actionable for people. Either on Twitter (though that seems a bit limited)
>>>>> or using Google Forms [1], which is my preference.
>>>>>
>>>>> I'll prepare something and share it with you soon. If the survey looks
>>>>> good, we can promote it on Twitter and during the Hackergarten at J1 (of
>>>>> course talking to people in person there will be a great chance to learn
>>>>> about their wishes, too).
>>>>>
>>>>> It'd be nice if we got some insight from that.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> --Gunnar
>>>>>
>>>>> [1] https://docs.google.com/forms/
>>>>>
>>>>>
>>>>> 2016-09-09 11:34 GMT+02:00 Marco Molteni <moltenma(a)gmail.com>:
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> which is the best / common way to get a representative feedback
>>>>>> according to your experience?
>>>>>> Thanks!
>>>>>>
>>>>>> On Thu, Sep 8, 2016 at 7:44 AM, Christian Kaltepoth <
>>>>>> christian(a)kaltepoth.de> wrote:
>>>>>>
>>>>>>> I also think that adding the most popular 3rd party constraints
>>>>>>> directly to the spec is a good thing. Especially @NotBlank and @NotEmpty.
>>>>>>>
>>>>>>> However, I also agree that it would be nice to gather more feedback
>>>>>>> from the community to learn which constraints people would like to see in
>>>>>>> the spec.
>>>>>>>
>>>>>>> 2016-09-06 20:50 GMT+02:00 Michael Nascimento <misterm(a)gmail.com>:
>>>>>>>
>>>>>>>> +1 to including them.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Michael
>>>>>>>>
>>>>>>>> On Mon, Aug 22, 2016 at 2:37 PM, Marco Molteni <moltenma(a)gmail.com>
>>>>>>>> wrote:
>>>>>>>> > Hi all,
>>>>>>>> >
>>>>>>>> > It would be possible to add some built-in constraints to the V
>>>>>>>> 2.0?
>>>>>>>> >
>>>>>>>> > @NotBlank, @NotEmpty, @Length are used very often in projects,
>>>>>>>> they are
>>>>>>>> > already present in Hibernate Validator and their implementation
>>>>>>>> is well
>>>>>>>> > defined.
>>>>>>>> >
>>>>>>>> > What do you think?
>>>>>>>> >
>>>>>>>> > Here a list of the most used constraint for GitHub's projects
>>>>>>>> (the numbers
>>>>>>>> > change at every request but you get the idea. HV = Hibernate
>>>>>>>> Validator, BV =
>>>>>>>> > Bean Validation):
>>>>>>>> >
>>>>>>>> > 189'143 - BV - NotNull
>>>>>>>> > 56'902 - BV - Size
>>>>>>>> > 39'551 - HV - NotEmpty <-
>>>>>>>> > 20'687 - HV - NotBlank <-
>>>>>>>> > 17'735 - BV - Pattern
>>>>>>>> > 16'763 - HV - Email
>>>>>>>> > 16'033 - BV - Min
>>>>>>>> > 12'769 - HV - Length <-
>>>>>>>> > 7'806 - BV - Digits
>>>>>>>> > 4'982 - BV - Max
>>>>>>>> > 4'971 - BV - Past
>>>>>>>> > 3'598 - BV - DecimalMin
>>>>>>>> > 2'753 - BV - AssertTrue
>>>>>>>> > 2'379 - BV - DecimalMax
>>>>>>>> > 2'308 - BV - Future
>>>>>>>> > 1'999 - HV - Range
>>>>>>>> > 1'497 - HV - URL
>>>>>>>> > < 1'000 other constraints
>>>>>>>> >
>>>>>>>> > Thanks
>>>>>>>> >
>>>>>>>> > Cheers
>>>>>>>> >
>>>>>>>> > Marco
>>>>>>>> >
>>>>>>>> >
>>>>>>>> > _______________________________________________
>>>>>>>> > 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
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Christian Kaltepoth
>>>>>>> Blog: http://blog.kaltepoth.de/
>>>>>>> Twitter: http://twitter.com/chkal
>>>>>>> GitHub: https://github.com/chkal
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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
>>>>>>
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>>
>>
>> _______________________________________________
>> beanvalidation-dev mailing list
>> beanvalidation-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>
>
7 years, 1 month
Happy Holidays and State of the Union
by Gunnar Morling
Hi,
As the year's end is approaching, I'd like to wish everyone Happy
Holidays and a great year 2017! I hope you can relax a bit during the
holidays and have a great time with your loved ones.
Also let me say a big "thank you" for all your contributions to Bean
Validation 2.0; all the proposals, discussions, reviews etc. have been
very valuable and are appreciated very much. I think we've made some
good progress already, with some easy wins already merged and more
complex matters such as type-level constraints having advanced quite a
bit.
While waiting for some more feedback on the latest revision of the
extractor proposal [1], I'm finally getting back to the proposal for
java.time support. The API change has already been merged, the RI will
follow closely and you can expect a pull request for the spec update
very soon.
With these two things (value extractors, java.time support) in place
at least in some preliminary form, I think we are in good shape for a
first preview release of the spec. Is there anything missing that you
think should absolutely be in the first preview? My goal is to do the
release early in January. I hope we can get some feedback from the
wider community based on this.
Subsequently, we should pick up some other loose ends such as the
validateValues() idea (BVAL-214) and other things like constraint
ordering (BVAL-248), separation of message interpolation and message
bundle retrieval (BVAL-217) and more.
All, thanks again for your efforts with this spec. I'm looking forward
to making BV 2.0 happen together with you in 2017!
--Gunnar
[1] http://lists.jboss.org/pipermail/beanvalidation-dev/2016-December/001140....
7 years, 3 months
Value extraction open issue #2: per constraint ConstraintsApplyTo?
by Guillaume Smet
Hi,
This is the first of a series of threads about the open questions regarding
value extraction [1]. We hope having a separate thread per question will
help having a more structured and easy to follow discussion.
Summary of the issue
================
ConstraintsApplyTo only allows one behavior per annotated element. Should
it be per constraint? E.g. for @NotNull @Email StringProperty email it may
be desirable to apply @NotNull to the wrapper but @Email to the wrapped
value. That’s not possible currently.
Summary of the discussions going on
============================
Matt proposed something like:
@ConstraintsApplyTo(target=WRAPPED_VALUE, constraintTypes=Size.class)
@Size(3)
List<String> nicknames;
As noted by Emmanuel, it does not solve the issue when you want 2 @Size
constraints, one for the List and the other for the enclosed String.
Emmanuel proposed to use groups to solve this issue:
"
But it makes me think that we sorta addresssed a similar class of problem
with groups.
I haven’t explored at all but could we something similar by subverting
groups. Let’s define two special groups: OnContainer OnWrappedValue
@Min(value3, groups=OnWrappedValue.class)
List<String> nicknames;
"
[1] http://beanvalidation.org/latest-draft/spec/#_open_questions
7 years, 3 months
Value extraction open issue #9: extractors for specific parameterized types
by Gunnar Morling
Hi,
Another one from the open issues list: Should we allow extractors to
be defined for specific parameterized types, e.g.:
public class ListOfIntegerExtractor implements
ValueExtractor<List<@ExtractedValue Integer>> { ... }
public class ListOfStringExtractor implements
ValueExtractor<List<@ExtractedValue String>> { ... }
Currently, a value extractor may only mark a wild-card type parameter
with @ExtractedValue:
public class ListOfStringExtractor implements
ValueExtractor<List<@ExtractedValue ?>> { ... }
The reason being to cut down on complexity and the lack of any use
case. Is there any scenario where one would want to extract a list of
Integer differently than a list String?
I would thus only support wildcard type parameters in extractor
definitions, unless someone else can see a compelling use case for the
more liberal model. Note we always can relax the requirement in a
future revision.
Thanks,
--Gunnar
7 years, 3 months
Value extraction open issue #7: Should type argument constraints trigger cascaded validation?
by Gunnar Morling
Should the presence of type argument constraints alone trigger
cascaded validation E.g. consider the case of Tuple:
class Tuple<T1,T2> {
@NotNull T1 getT1();
@Min(3) getSize();
// ...
}
When validating
class TupleUser {
Tuple<@Min(1) Integer, @Email String> tuple;
}
should this trigger cascaded validation of "tuple", i.e. validation of
@NotNull and @Min within the Tuple class itself?
A variation of the issue is
Map<AddressType, @NotNull Address> myMap;
where validation of "myMap" would cause validation of @NotNull for the
map values, but should it also cause validation of constraints
declared on Address?
Currently, the sole presence of type argument constraints would not
trigger such cascaded validation. You'll need to put @Valid in place
to do so:
@Valid
Tuple<@Min(1) Integer, @Email String> tuple;
Map<AddressType, @NotNull @Valid Address> myMap;
I found such implicit cascaded validation semi-attractive at some
point, but since then have come to think that requiring @Valid is the
better alternative, as it's more consistent with the 1.1 behaviour.
I *think* Matt and Emmanuel support that @Valid should be required
(but confirmation would be nice). What do others think?
--Gunnar
7 years, 3 months
Improved java.time support follow-up
by Guillaume Smet
Hi and happy new year to everyone!
We discussed a couple of things today with Gunnar and we have a couple of
questions for you all regarding the improved java.time support we committed
before the holidays.
1. Support for partials
================
The initial proposal of Michael included the support for partials such as
YearMonth or MonthDay (ie types which do not strictly represent a point in
time).
While @Past and @Future make sense for YearMonth, it's a bit more difficult
to define them for MonthDay.
The implementation we committed indeed supports MonthDay by building a
MonthDay from the Clock provided by the ClockProvider and comparing them
using MonthDay.compare(...).
We tried to think of a use case but couldn't think of any.
Partials currently supported are:
- LocalTime
- MonthDay
- OffsetTime
- Year
- YearMonth
I think Year and YearMonth can be considered OK without further discussion.
LocalTime and OffsetTime, I can think of use cases. MonthDay, well, I
didn't find any potential use case and it looks just weird.
That being said, it does not cost us anything to have it for consistency.
So, any thoughts on this? Use cases, votes for removing it/keeping it?
2. Resolution
==========
In the comments of https://hibernate.atlassian.net/browse/HV-820, someone
suggested the idea of resolution.
You could have something like:
@Future(resolution = ChronoUnit.MONTHS)
private LocalDate paymentDate;
This would truncate the LocalDates to ChronoUnit.MONTHS before doing the
comparison, ensuring that the date should be at least next month.
It might also be useful to reduce the resolution of ZonedDateTimes to days
before doing the comparison, especially when using the orPresent option.
Note that it's only useful if you use a type more precise than what you
require for the validation so it might be a very narrow use case not worth
adding additional complexity to the standard constraints.
Do you see any use cases for that? Have you ever used custom constraints
for that?
3. orPresent
=========
The current implementation adds orPresent support as an option of the
preexisting @Past/@Future annotations:
@Past(orPresent = true) / @Future(orPresent = true)
Gunnar suggested this afternoon that it might be more readable to have
@PastOrPresent/@FutureOrPresent, especially if we have more than one
options for @Past/@Future.
Something like @Past(resolution = DAY, orPresent = true) would be less
readable than @PastOrPresent(resolution = DAY).
Personally, I prefer having one annotation with an option rather than 2
different annotations - I think it has a better semantic - but I can see
the rationale behind Gunnar's proposal.
Thoughts?
Thanks.
--
Guillaume
7 years, 3 months
Updated proposal for container value extraction
by Gunnar Morling
Hi,
It has been silent on the surface, but that doesn't mean we haven't been busy :)
I've spent some time working on a proof of concept implementation of
the value extraction proposal (BVAL-508) which has been added to the
RI earlier this week [1]. This effort brought a fair bit of insights
and clarity which is reflected in an updated proposal that you can
find at [2].
So if you can spend some time and review it, that'd be much
appreciated. It's a bit more formalized than the original proposal and
also takes an opinion on some of the original questions. I tried to
cut down a bit on the many loose ends to advance the matter a bit, but
if you are doubtful about any of the directions taken, please speak
up.
Also the ValueExtractor contract has evolved a bit. It now allows for
a nicely uniform, yet efficient implementation of the single value and
multi value case. Refer to the pull request for the details. There are
some open questions at the end of the document. Feedback on these (and
of course any other parts of the document) are highly welcome. I've
checked on the previous threads and discussions of the matter (e.g.
Hendrik's extensive feedback) and hope the proposal covers all the
essential items. Please let me know if anything is missing.
The idea is that we add this version of the proposal as an appendix to
the spec, adjust the RI to conform with it (it already does more or
less) so we can aim for a first alpha release of spec and RI very
early next year. That will allow people to get their hands on this
feature and play around with it a bit, hopefully resulting in some
more feedback from the outside, too.
My main remaining questions are:
* Is allowing to put constraints to an element but automatically
applying them to the wrapped value the right thing to do? I can see
the concerns about lacking comprehensibility (it's working based on
the presence of an automatically unwrapping value extractor), but then
it's needed to support "@Email StringProperty email"
* Should we support nested collections (e.g. List<Map<String, @NotNull
String>> addressesByType). It hasn't been supported before, but I can
see how it's more appealing with type parameter constraints. But it
adds complexity, too.
Looking forward to your feedback,
--Gunnar
[1] https://github.com/hibernate/hibernate-validator/pull/592
[2] https://github.com/beanvalidation/beanvalidation-spec/pull/116
7 years, 3 months
Diff with changes done for Bean Validation 2.0
by Gunnar Morling
Hey,
Thanks to the help of Guillaume, we now have a way to view the full
diff of changes done for the Bean Validation 2.0 spec.
You can find the link(s) under "Resources" on
http://beanvalidation.org/specification/. This gets you to diffs of an
AsciiDoc file containing the full spec, with all sources included. As
we pull in actual source files from the beanvalidation-api into the
spec, getting the full picture was rather inconvinient before.
The GitHub diff view takes a bit to load, I hope it continues to work
as the number of changes grows. You also can view the diff locally by
running "git diff" on the "spec-full" branch of the
beanvalidation-spec repo.
Having a coloured diff of the output (HTML) would be a tad nicer, but
it's not supported by AsciiDoc currently. If needed, we may experiment
with some external HTML diff tools, but I think so far the AsciiDoc
diff isn't too bad (after all, AsciiDoc is meant to be human readable
by itself). It already helped to find a few glitches that had sneaked
in.
--Gunnar
7 years, 3 months