Re: [hibernate-dev] On possible extensions for the validator
Cross validation marker annotations like @ExactlyOneNull are not really actual constraints
(ie annotated with @Constraint) because somehow they must carry two logic:
- the property checking logic
- the "aggregation" logic
Besides these markers should be ignored by the rest of the Bean Validation execution (they
don't mean anything in isolation).
With that in mind I would say that:
- we should logically forbid BV groups and cross validation groups to reuse the same
interface to limit confusion. Ideally a different name for the two concepts would be
better.
- in practice, they live in different spaces BV constraints host BV groups and cross
validation constraints host cross validation groups. They never interfere. So the
iplmentation does not really care if the same interface is reused.
By the way @CrossValidation can host BV groups as it's a regular constraint.
Back to cross validation use cases, could we list 3 or 4 use cases of cross validations
and what do we expect them to do (error report wise). That will help to define the generic
mechanism to define cross validation markers and implementations, as it is today, it seems
@ExactlyOneNull would be hardcoded.
Frankly, I wonder if the cross validation solution will end up being more verbose than the
raw class-level approach :)
On 18 oct. 2010, at 11:11, Hardy Ferentschik wrote:
I was also thinking about a generic class level @CrossValidation
constraint. I think Emmanuel and I
are thinking about the same thing here:
@CrossValidations({
@CrossValidation(forGroup=BankAccount.class),
@CrossValidation(forGroup=ContactDetails.class)
})
public class BankAccountNumber {
@ExactlyOneNull(groups=BankAccount.class)
public String getIBAN() {
return IBAN;
}
@ExactlyOneNull(groups=BankAccount.class)
public String getAccount() {
return account;
}
@ExactlyOneNull(groups=ContactDetails.class)
public String getHomeNumber() {
return homeNumber;
}
@ExactlyOneNull(groups=ContactDetails.class)
public String getWorkNumber() {
return workNumber;
}
}
Using groups (or maybe payloads!?) you can have multiple cross validations of the same
type within one entity.
--Hardy
On Mon, 18 Oct 2010 09:48:16 +0200, Emmanuel Bernard <emmanuel(a)hibernate.org>
wrote:
>
> On 16 oct. 2010, at 10:56, Dag Hovland wrote:
>
>> On 15/10/10 13:33, Emmanuel Bernard wrote:
>> (...)
>>> That being said, I wonder whether you can write your approach atop a generic
class-level constraint @CrossValidation that would look for the properties annotations and
behave as expected. That would be a nice way to offer both world to the users. You will
need to "group" cross field constraints though: as I see it on the paper, you
can only have one group of cross level constraint for a given constraint type per class.
>>
>> I do not really understand this. Can you give an example?
>
> class BrokenModel {
> @AtLeastOneNotNullAmongst(Group1.class)
> A getA() { ... };
> @AtLeastOneNotNullAmongst(Group1.class) @AtLeastOneNotNullAmongst(Group2.class)
> B getB() { ... };
> @AtLeastOneNotNullAmongst(Group2.class)
> C getC() { ... };
> }
>
> A or B must be not null and B or C must be not null.
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev