Short Circuit validation with composed constraints?

pediddle · **Joined:** Sun Feb 27, 2011 11:40 am **Posts:** 8

I want my custom validator to perform a DB query. I get an SQLException if the query parameter exceeds the column size. So, why can't I simply compose constraints?

Code:

@ReportAsSingleViolation
@Size(max=10) // avoid exception? I wish...
@Constraint(validatedBy=MyObjectExistsValidator.class)
...
public @interface MyObjectExists {...}

Code:

public class MyObjectExistsValidator ...
    public boolean isValid(String value, ConstraintValidatorContext context) {
        return null != getEntityManager().find(MyObject.class, value); // simplified query for example
    }
}

This is a matter of both DRY and performance. (In reality, I have another custom annotation instead of @Size, the query is more complex...) If I use @ReportAsSingleViolation, and one of the composed constraints fails first, then what possible good is it to invoke the custom validator anyway? (Looking at HV 4.1.0.Final - ConstraintTree.java line 123 -- it should simply "return".)

hardy.ferentschik · **Posted:** Fri Apr 15, 2011 2:34 am

Hi,

I have no idea what problem you actually have. Why do you think something is wrong w/ your custom composed constraint?
Also, be careful w/ using the entitymanager in the constraint validator implementation - http://community.jboss.org/wiki/Accessi ... tValidator

--Hardy

pediddle · **Joined:** Sun Feb 27, 2011 11:40 am **Posts:** 8

Thanks Hardy. The problem is the custom validator is executed whether or not the composed constraints fail, even if it can't affect the result due to @ReportAsSingleViolation. This seems wasteful, but more importantly, I'm forced to reimplement checks like @Size to avoid exceptions. It just seems like a big gap that there's no short circuiting behavior save the un-obvious and unwieldy use of groups(First.class) and groups(Second.class) that I've seen recommended. (Maybe if @GroupSequenceProvider could be standardized and configured via XML...?)

For comparison, I noticed that the non-standard @ConstraintComposition(OR) does short circuit (just not in the way I need).

I'll review the link you gave. Thanks!

hardy.ferentschik · **Posted:** Fri Apr 15, 2011 10:25 am

Quote:

The problem is the custom validator is executed whether or not the composed constraints fail, even if it can't affect the result due to @ReportAsSingleViolation.

I see what you are saying and one could probably optimize that. However, as long as the exact behavior is not specified in the Bean Validation specification it would be nothing one could rely on.

Quote:

This seems wasteful, but more importantly, I'm forced to reimplement checks like @Size to avoid exceptions.

Per definition there is no order on the evaluation unless you are working w/ groups. Feel free to make suggestions to the Bean Validation 1.1 spec.

Best approach for now is to work with groups.

--Hardy

sanne.grinovero · **Posted:** Sun Apr 17, 2011 2:17 pm

if you enabled short-circuiting of multiple validators, people won't get a full list of failed constraints but just the first for each attribute - that's not what I would expect when validating a user input form for example, and most of the time validators execute cheap operations.

I agree this would be very useful in some cases, but make sure it doesn't mess with current behaviour. Maybe an additional annotation expressing concepts as "expensive" or "skippable" ?