2:04 a.m.
On 12 Jan 2017, at 19:45, Matt Benson <mbenson(a)apache.org>
wrote:
> 2. Should @ConstraintsApplyTo be usable per-constraint?
> Doing such seems like it could be a bit clumsy, but it might be okay if
@ConstraintsApplyTo were repeatable and included Class<? extends Annotation>[]
constraintTypes() default {} element which, if non-empty, could differentiate which
constraints applied to the wrapper vs. the extracted value.
Do you mean?
@ConstraintAppliesTo(target=WRAPPED_VALUE, constraintTypes=Min.class)
@Min(3)
List<String> nicknames;
This approach cannot cover a case were the Min constraint it used one for the container
and one for the wrapped value.
That is what I was postulating, yes. Min might not be the best example. NotNull might be
a better example of a constraint that one would want to apply both to the wrapper and the
extracted value.
In this case, let’s use @Size whbich would make the example valid. A list of at least 3
elements vs a nickname of at least 3 characters.
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;
// note that these examples are simplifications and should really be written List<@Min
String> nicknames;
// but pretend we have a subclass of List<String> with no way to put a TYPE_USE
constraint
The idea is kind of cute (for lack of a better word), but doesn't this complicate or
prevent "normal" use of validation groups?
Right, it needs to be explored enough to qualify or be rejected.
I * think* that since groups are additive in nature and if we disallow people to use these
special groups in sequences and other groups, they would not interfere at all.
This proposal would not address the case of multiple nestsed containers
List<List<String>>
I agree that specifying WRAPPED_VALUE per-property is ambiguous for
List<List<String>>. Maybe that is an argument against allowing #8. What if the
rule were that @ConstraintsApplyTo(WRAPPED_VALUE) is valid on TypeExtractor class
definitions, while @ConstraintsApplyTo(ANNOTATED_ELEMENT) is valid elsewhere, serving only
to override the behavior specified by the extractor? Then you could have @Size(min=5)
@ConstraintsApplyTo(ANNOTATED_ELEMENT) List<@Size(min=3)
@ConstraintsApplyTo(ANNOTATED_ELEMENT) List<String>> . This still doesn't
solve #2, but I think the problems are orthogonal.
I suppose this assumes that most if not all extractor would have
@ConstraintsApplyTo(WRAPPED_VALUE) set so that a user has the option to do annotated
element vs wrapped value on site. That would be a bad default for iterable and break BV
1.1 semantic in a backward incompatible way (without @ConstraintsApplyTo on site, my @Min
annotation would not longer validate the container size but what’s inside.
Plus the example you give is just bad practice and illogical to quote Spok.
@Size(min=5) @ConstraintsApplyTo(ANNOTATED_ELEMENT) List<@Size(min=3)
@ConstraintsApplyTo(ANNOTATED_ELEMENT) List<String>>
If you can plance constraints where you want, place then where they are the more natural
and in this case the example is rewritten
@Size(min=5) List<@Size(min=3) List<@Size(min=3) String>>
The problema rises when you have class Matrix extends List<List<String>> {}
You have no place to put @Size(min=3) and @Size(min=24)
@Size(min=5)
@Size(min=3) //I want to be in the inner list
@Size(min=24) // I want to be in the most inner wrapped element
Matrix matrix;
TODO: I think I’m fine with not supporting such case and support #8 personally.
> 7. Should the presence of type argument constraints alone trigger nested
validation?
> I can appreciate the sense of the consistency argument to requiring @Valid, but in
practice it seems reasonable to me that @Valid be implied. It probably would be much
simpler to require @Valid from an implementation perspective, however.
I personally am a bit reluctant. Do we really think that this is the default behavior
people will want? Because you cannot negate a @Valid today so that’s a definitive
decision. It seems to be that many containers are not beans per se and don’t want their
properties to be validated, just the extacted stuff,.
Are you saying that type argument constraints will be validated using extraction, but
that only validation of the Map object *itself* would depend on @Valid to trigger
validation of Map values per BV 1.x? So if Address had validation metadata, you could
have:
Map<AddressType, @NotNull Address>
And BV would validate that the values were non-null, but would not invoke Address
validation without @Valid on the Map (BV 1.x) or on the Address type parameter? That makes
sense to me. You could then combine:
Map<AddressType, @NotNull @Valid Address>
Your understanding is correct, to validate the properties of Address, you need the @Valid
annotation.
What the question 7 is about though is a bit different, I think (I’m confused now too :)
)
Assume the following container class
class Tuple<T1,T2> {
@NotNull
T1 getT1();
@Min(3)
getSize();
...
}
Does the following validate that Integer is not null, does it validate that tuple size is
at least 3?
Tuple<@Min(1) Integer, @Email String> tuple;
Is that a fair understanding of the question Gunnar ?