8:06 p.m.
Hi,
we managed to implement a first version of boolean composition for the
validator, and it seems to require very few changes to the code.
We also opened an issue on Jira about that.
From the tests we ran, the constraints seem to be evaluated correctly,
but we have some strange behaviour regarding the reporting of
violations, which we are investigating.
Reporting violations would also be an interesting subject of discussion
in itself, since we cannot say anymore that a composed constraint fails
if just one of the constraint
composing it fails. We have to evaluate all the tree of constraints
before knowing the final outcome (if it is a disjunction for example).
In this case we thought it might be best to report everything as a
single violation by default.
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?
In other words, do we assume that unless the user specifies @NotNull, it
means that a null value is valid and should not generate an exception
for other constraints?
Federico
10:55 a.m.
we managed to implement a first version of boolean composition for
the
validator, and it seems to require very few changes to the code.
Nice :)
We also opened an issue on Jira about that.
I added some comments to
http://opensource.atlassian.com/projects/hibernate/browse/HV-390
If you want to get some feedback regarding the code I suggest you attach a
patch to the
issue or you use the new possibilities we have now through the move to git
(http://github.com/hibernate/hibernate-validator) by forking the validator
repo.
From the tests we ran, the constraints seem to be evaluated
correctly,
but we have some strange behaviour regarding the reporting of
violations, which we are investigating.
Reporting violations would also be an interesting subject of discussion
in itself, since we cannot say anymore that a composed constraint fails
if just one of the constraint
composing it fails. We have to evaluate all the tree of constraints
before knowing the final outcome (if it is a disjunction for example).
In this case we thought it might be best to report everything as a
single violation by default.
I think the composing constraint needs still to honor things like
@ReportAsSingleViolation.
In case of a disjunction - if all validation fails I think you should get
the violation
errors for all of them (unless @ReportAsSingleViolation is used). As soon
as one
validation succeeds you don't get any validation error.
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."
--Hardy
1:37 p.m.
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.
10:54 a.m.
On 15/10/10 10:55, Hardy Ferentschik wrote:
I added some comments to
http://opensource.atlassian.com/projects/hibernate/browse/HV-390
If you want to get some feedback regarding the code I suggest you attach a
patch to the
issue or you use the new possibilities we have now through the move to git
(http://github.com/hibernate/hibernate-validator) by forking the validator
repo.
Thanks. I will upload a diff hopefully tomorrow, we had some (irrelevant) practical
problems :)
I think the composing constraint needs still to honor things like
@ReportAsSingleViolation.
In case of a disjunction - if all validation fails I think you should get
the violation
errors for all of them (unless @ReportAsSingleViolation is used). As soon
as one
validation succeeds you don't get any validation error.
Ok. For disjunction ("OR") we will change it as you suggest. A larger problem is
with negation,
called "ALLFALSE". ALLFALSE means that the conjunction of the negations should
hold, that is, all
the composed constraints should fail. If everything leading to ALLFALSE failing should be
reported,
the validator would need to keep track of all _succeeding_ constraints. (Reporting the
failing
constraints when ALLFALSE fails would give exactly the messages we do not want to show.)
So I
believe that for ALLFALSE, the annotation should always be treated as though it has
@ReportAsSingleViolation.
> 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.
If this is the case, we believe "@NotNull" should always be seen as a
conjunction. It should, for
example, not be part of an "OR". For example:
@NotNull
@Size(min=2,max=10)
@Bool(OR)
@SomeConstraint{...}
would not really make sense, since if @NotNull fails, @Size would hold.
Regards,
Dag Hovland
4948
days inactive
4950
days old
3 comments
4 participants
participants (4)
-
Dag Hovland -
Emmanuel Bernard -
Federico Mancini -
Hardy Ferentschik