[hibernate-issues] [Hibernate-JIRA] Commented: (HV-390) Boolean composition of constraints

[Federico Mancini (JIRA)]

    [ http://opensource.atlassian.com/projects/hibernate/browse/HV-390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=38804#action_38804 ] 

Federico Mancini commented on HV-390:
-------------------------------------

Yes, violation reporting with boolean constraints is a pain. I understand what you mean with {{ALL_FALSE}}. It is not easy to come up with meaningful default messages, especially when a constraint should be reported as failed even if it actually succeeded. How do you use the customized error message in this case? That is why our first instinct was to just hide the complexity of the boolean tree defined by a composed annotation behind a default @ReportAsSingleViolation.

The problem as I see it is mainly that, as long as you allow only {{AND}}, you don't really have a constraint tree to evaluate, but a list. Whenever a single constraint fails, you can stop and say that there is a violation. No matter how nested the contraint was in the composed annotation.
That is, such composed annotations, do not really define new constraints, they are only a container. That is why it makes sense to want to report the single violations form inside the container: because their individual meaning is preserved, just as they where written individually on the property to validate.

When instroducing boolean operators, you have to evaluate the constraints in a tree-like fashion, and it makes a difference where the constraints that fails is in the tree.
In this case you are really defining a new constraint with a new meaning, where its composing parts do not make much sense alone.

If some user really still wants to see a list of all composing constraints that caused the violation, I can suggest we try to report the violations in a tree structure mirroring the way the constraints are composed.
In this way the violations would be grouped by boolean operator, and a meaningful message could be given for each subtree.

The user could then decide how many levels of this tree he would want to be reported or shown, since I think the context in which a constraint fails is as important as the constraint itself.

> Boolean composition of constraints
> ----------------------------------
>
>                 Key: HV-390
>                 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-390
>             Project: Hibernate Validator
>          Issue Type: New Feature
>          Components: engine
>            Reporter: Federico Mancini
>            Assignee: Hardy Ferentschik
>             Fix For: 4.2.0
>
>         Attachments: modified classes.zip
>
>
> By adding a built-in annotation @Bool (or some other name) with element values OR, ALLFALSE and AND (which would be the default) it would be possible to 
> compose constraints in a boolean fashion.
> For example:
> {code}
> //Specify that at least one of the patterns must match
> @Bool(OR)
> @List({@Pattern(regexp="pat1"), at Pattern(regexp="pat2"), at Pattern(regexp="pat3"), at Pattern(regexp="pat4")})
> @interface WhiteList{..}
> {code}
> {code}
> //Specify that none of the patterns must match
> @Bool(ALLFALSE)
> @List({@Pattern(regexp="pat1"), at Pattern(regexp="pat2"), at Pattern(regexp="pat3"), at Pattern(regexp="pat4")})
> @interface BlackList{..}
> {code}
> {code}
> //At least on valid contact method must match
> @Bool(OR)
> @Email
> @Address
> @Phone
> @interface ContactDetails{...}
> {code}
> This would greatly increase the type of new constraints that can be defined just by reusing some existing ones.
> Possible extensions might be for example further operators like XOR (meaning exactly one of the constraints must hold) or similar.
> It seems like it is possible to implement this feature by adding very little code to just a couple of classes, and adding the new @Bool annotation to the API.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira