On 15 oct. 2010, at 10:55, Hardy Ferentschik wrote: >> >> Another thing we wondered about is the default behaviour of built-in >> constraints when they validate null values. Are they supposed to succeed >> on null values by default? > > That's a suggestion by the Bean Validation Specification. The spec says: > > "While not mandatory, it is considered a good practice to split the core > constraint > validation from the not null constraint validation (for example, an @Email > constraint will return > true on a null object, i.e. will not take care of the @NotNull validation) > null can have multiple meanings but is commonly used to express that a > value does not make sense, is not > available or is simply unknown. Those constraints on the value are > orthogonal in most cases to other constraints. > For example a String, if present, must be an email but can be null. > Separating both concerns is a > good practice."
I never liked the idea of having to treat null as a different kind of constraint. One of the advantage of the approach taken by the spec is that it's easier to the user (at the expense of the constraint implementor), will usually be less verbose and is simpler for the spec that does not have to treat null as special. _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
