[bv-dev] Ordered Validation (practically)

[Emmanuel Bernard]

I have what I think is a nice solution for BVAL-248 and for the uses case Cemo has

The issue in this case is that you want the logic of group sequence but only per target (property, class, annotation).

We can dot he following for that reusing HV-462's example

```
interface Cheap {}
interface Expensive {}

@GroupSequence(value={Cheap.class,Expensive.class}, ordering=PER_TARGET)
public class DomainObject {

	@Size(max=50, groups=Cheap.class) // constraint 1a
	@Pattern(regexp="[a-z]*", groups=Expensive.class)  // constraint 1b
	private String name;
	
	@Size(max=20, groups=Cheap.class) // constraint 2a
	@URL(groups=Expensive.class) // constraint 2b
	private String email;
	
	@Size(max=100, groups=Cheap.class) // constraint 3a
	@Pattern(regexp="[0-9]*", groups=Expensive.class) // constraint 3b
	private String password;
}
```

The default @GroupSequence.ordering would be GLOBAL which is the current behavior.

This solution is not technically as orthogonal than a true salience model but would that work for the use cases you have in mind?

We can apply the same kind of solution on @ReportAsSingleViolation

What do you think?

Emmanuel

On 4 janv. 2012, at 14:58, Hardy Ferentschik wrote:

> Ordered constraints came up several times on the Hibernate Validator mailing list as well. 
> There is a Hibernate Validator specific issue [1] as well as a BVAL one [2]
> 
> [1] https://hibernate.onjira.com/browse/HV-462
> [2] https://hibernate.onjira.com/browse/BVAL-248
> 
> 
> On Jan 4, 2012, at 2:29 PM, Emmanuel Bernard wrote:
> 
>> Hi,
>> Let me try and summarize what you want to be sure we are on the same page:
>> 
>> - you want sometimes to return one and only one failure per property
>> - you want some constraints to be validated before others (to be the one displayed)
>> 
>> Besides not empty which should be simply ignored by your unique email constraint, do you have other use cases? I would rather exclude null / empty from the list of use cases because it's a fairly pathological case and we plan on addressing that via a different mechanism (namely a way to mark a constraint validator as being called only on non null / non empty values).
>> 
>> I've been trying to avoid numerical ordering (the fancy name is salience I believe) so far so I'd like to see concrete use cases that cannot be solved otherwise.
>> 
>> Having a per property shortcut and a global shortcut would be a nice a easy feature to add. We left it out of 1.0 but it almost made it through.
>> 
>> Likewise, we could fake salience by providing a special group
>> 
>> ```
>> package javax.validation.groups;
>> 
>> @GroupSequence({Level1.class, Level2.class, Level3.class, Level4.class, Level5.class, Level6.class, Level7.class, Level8.class, Level9.class, Level10.class})
>> interface Order {
>>    interface Level1 {}
>>    interface Level2 {}
>>    interface Level3 {}
>>    ...
>>    interface Level10 {}
>> }
>> ```
>> 
>> Frankly I'd rather avoid it but that would work.
>> 
>> On 3 janv. 2012, at 21:33, Cemo wrote:
>> 
>>> Hi experts,
>>> 
>>> After reading your comments and mail list I realized that it will be better share our opinions here about our problems.
>>> 
>>> First, I would like to thanks all of you to provide such an elegant library and spec. After latest improvements at spring side, I am sure that bean validation will be defacto validation framework among java community.
>>> 
>>> The only problem We are facing is that ordered validations.
>>> 
>>> In a common sense validation such this can be feasible: 
>>> 
>>> public
>>> class AccountBean {
>>> 
>>>   @CheapValidation(groups=Name1.class)
>>>   @ExpensiveValidation(groups=Name2.class)
>>>   @VeryExpensiveValidation(groups=Name3.class)
>>> 
>>> String
>>> name;
>>> 
>>>   @CheapValidation(groups=Surname1.class)
>>>   @ExpensiveValidation(groups=Surname2.class)
>>>   @VeryExpensiveValidation(groups=Surname3.class)
>>> 
>>> String
>>> surname;
>>> 
>>> 
>>> public interface
>>> Name1 {}
>>> 
>>> public interface
>>> Name2 {}
>>> 
>>> public interface
>>> Name3 {}
>>>   @GroupSequence({Name1.class, Name2.class, Name3.class})
>>> 
>>> public interface
>>> Name {}
>>> 
>>> 
>>> public interface
>>> Surname1 {}
>>> 
>>> public interface
>>> Surname2 {}
>>> 
>>> public interface
>>> Surname3 {}
>>>   @GroupSequence({Surname1.class, Surname2.class, Surname3.class})
>>> 
>>> public interface
>>> Surname {}
>>> }
>>> 
>>> 
>>> 
>>> There is two common usage for this. The first usage: some validations are expensive that should be runned if all validations pass. Another usage is for each field there should be one violation. For email, if it is empty, uniqueEmail constraint must not be checked. I hope that how much necessary it is for us you can imagine. Almost all fields has such restrictions. Ordering and shortcutting are crucial for us.
>>> 
>>> But just to provide validation order and shortcut GroupSequence is practically  impossible to use at enterprice level. For each field again and again we are declaring interfaces. It is not only intuitive but also seems ugly. By the way what is came to my mind is for each constraint, declaring a order like this:
>>> 
>>> public
>>> class AccountBean {
>>> 
>>>   @CheapValidation(order=0,groups=Name1.class)
>>>   @ExpensiveValidation(order=1,groups=Name2.class)
>>>   @VeryExpensiveValidation(order=2,groups=Name3.class)
>>> 
>>> String
>>> name;
>>> 
>>>   @CheapValidation(order=0,groups=Surname1.class)
>>>   @ExpensiveValidation(order=1,groups=Surname2.class)
>>>   @VeryExpensiveValidation(order=2,groups=Surname3.class)
>>> 
>>> String
>>> surname;
>>> }
>>> 
>>> 
>>> Default value for ordering might be same for all constraints.
>>> 
>>> Please help community. :) 
>>> 
>>> Thanks & happy new year  
>>> _______________________________________________
>>> beanvalidation-dev mailing list
>>> beanvalidation-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>> 
>> _______________________________________________
>> beanvalidation-dev mailing list
>> beanvalidation-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> 
> 
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev