I agree with Matt here. 

I would prefer to be consistent over dropping consistency for improved performance in some cases. 

So +1 for allowing constraints on both fields and getters.


2016-12-02 17:22 GMT+01:00 Matt Benson <mbenson@apache.org>:
As far as this goes, I agree that it makes sense to be flexible and consistent with earlier specification versions; i.e. to permit annotation of type parameters both on fields and their associated accessor methods.

With regard to the mechanism used for reaching the validated contained values, my feeling is that some combination of the proposals at [1] is correct (i.e. the explicitness of the original proposal plus the aspect of your proposal to combine the extracted value with the associated path/node). It would probably also be helpful to provide an annotation-based shorthand for class developers to mark the extracted elements of custom container types without having to write an extractor implementation (which ties into my otherwise clueless response on an earlier thread ;) ). 



On Dec 2, 2016 9:20 AM, "Gunnar Morling" <gunnar@hibernate.org> wrote:

As you may have seen, Emmanuel started a survey on how people would like to use type-level constraints in Bean Validation: http://beanvalidation.org/news/2016/11/23/survey-constraints-and-parameterized-type/

While we are waiting for some more replies to that one, I started with a PoC implementation of the value extractor idea in the reference implementation in order to get a better feeling for it, it's limitations, open questions etc.: https://github.com/hibernate/hibernate-validator/pull/592

One thing we started to wonder is whether it should be allowed to put type-level constraints to a field *and* the corresponding property getter at the same time:

    private List<@NotBlank String> strings;

    public List<@Pattern(regexp="...") String> getStrings() { return strings; }

My first inclination was to say that it should be supported (as you can put regular constraints to a field and its getter). A challenge is how to obtain the values for constraint validation. In the spirit of BV 1 we'd have to iterate the values directly from the field for evaluating the @NotBlank constraint and a second time through the getter for @Pattern validation. That's a potential performance issue of course.

What do others think?



beanvalidation-dev mailing list

beanvalidation-dev mailing list

Christian Kaltepoth
Blog: http://blog.kaltepoth.de/
Twitter: http://twitter.com/chkal
GitHub: https://github.com/chkal