[bv-dev] Constraint on non generic types (was Re: Support for constraints on container values (e.g. Collection<@Email String>))

[Emmanuel Bernard]

> On 7 Nov 2016, at 23:42, Hendrik Ebbers <hendrik.ebbers at me.com> wrote:
> 
> In addition I think that simply adding a constraints annotation to the generic type is wrong. All examples that we have mentioned are just perfect examples in that the generic type defines the content. Let’s say we have a class like this:
> 
> public abstract class ConvertableInteger<V> {
> 
> 	private int value;
> 
> 	public void setValue(int value) { this.value = value; }
> 
> 	public int getValue() { return value; }
> 
> 	public abstract V getConvertedValue();
> }
> 
> If you want to validate an instance of this class you normally want to validate the integer and not the converted value:
> 
> private ConvertableInteger<@Min(2_000_000) Date> myValue;
> 
> Such an expression looks like if you want to validate a Date object. In this case the better solution would be something like this:
> 
> @Min(2_000_000)
> private ConvertableInteger<Date> myValue;
> 
> And now we end in 2 different ways how we annotation value wrappers:
> 
> private CachableValue<@NotEmpty String> myCachedValue;
> 
> @Min(2_000_000)
> private ConvertableInteger<Date> myIntegerValue;

First off, your specific example does not work as is as the class is abstract. You would need an explicit subclass (e.g. DateConvertableInteger extends ConvertableInteger<Date>). And in that situation, The more natural BV approach would be to do this:

public class DateConvertableInteger extend ConvertableInteger<Date> {

    @Min(@2_000_000)
    public int getValue() { return value; }

    @NotEmpty
    public Date getConvertedValue();
}

class SomeClass {
    @Valid
    private StringConvertableInteger myValue;
}

== overriding constraint declarations

Now if you want a way to override the constraints of an embedded (@Valid) object (graph), then I think that is a different subject that we can try and address. JPA for example has the notion of @AttributeOverride. It is more complicated in the case of Bean Validation as we would need to override actual annotations. Not sure how to express that for now. Do we think that it is a valid and important requirement?

To clarify, here is what is required

public class Embeddable {
    @NotEmpty String foo;
}

public class Entity {
    @Valid @Override(path=“foo”, constraints=@Min(3)) // note that this is not valid Java syntax
    Embeddable embeddable;
}

== Constraint on non parameterized containers

That raises another question, the proposal allows to to three things:

- apply constraints on a type use generic declaration(*): Collection<@NotEmpty String> foo;
- apply constraints on specialized generic parameters (*): @Pattern(…) StringProperty prop; //where StringProperty extends Property<String>
- apply constraints on container with no generic: @Min(3) IntegerContainer prop; // where class IntegerContainer{ Integer value; } i.e. no generic

(*) I don’t know the actual proper names so sorry if I butchered notions

I am liking option 3 less and less and as far as I can remember, it does not rely on an explicitly identified use case. Who is wanting to support that usage, vs restrict the container feature to parameterized containers?

I’m not sure I was all that clear, so please ask any question if you have any doubt.

Emmanuel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20161121/bec3fa01/attachment.html