12:44 p.m.
I would like to revive the subject of reaching the same instance
multiple times in an object graph.
Assuming the following example
A |-> C -> B
|-> D -> B
Each arrow is an association marked as @Valid
Today, the second time an instance is reached, it is ignored.
So assuming B is invalid we can have c.b is invalid OR d.b is invalid.
I am getting more and more uncomfortable with that non-determinism.
Dhanji was not bothered arguing that in this case, a user can define
the order using groups. It's actually not possible as the same
constraint on B share the same groups definition.
An alternative proposal would look like that.
For a given object graph branch, the same instance cannot be validated
several times.
This would lead to the validation of the same object several times
provided it is in different branches
in the previous example, we would have two constraint violation reports:
- c.b is invalid
- d.b is invalid
Can you tell me on which side you are?
4:52 a.m.
On Wed, 18 Feb 2009 18:44:52 +0100, Emmanuel Bernard
<emmanuel(a)hibernate.org> wrote:
I agree there is a problem. I don't like the idea of getting two
constraint violations though.
Would it be an alternative to let ConstraintViolation.getPropertyPath()
return an array of
path strings?
--Hardy
5:45 a.m.
On Thu, 19 Feb 2009 11:38:32 +0100, Emmanuel Bernard
<emmanuel(a)hibernate.org> wrote:
Agreed. You could also introduce an additional method
ConstraintViolation.alternativePropertyPaths().
In the case where you don't care you can just use getPropertyPath and get
'a' path to the invalid object.
If your usecase require more information (and that's probably quite rare)
you can use alternativePropertyPaths.
The API gets more complex, but it's not harder to use for the most common
cases.
--Hardy
12:13 p.m.
Here is the new proposal
3.5.1. Object graph validation
The @Valid annotation on a given association (i.e. object reference or
collection / array of objects), dictates the Bean Validator
implementation to apply recursively the bean validation routine on
(each of) the associated object(s). This mechanism is recursive: an
associated object can itself contain cascaded references.
Null references are ignored.
To prevent infinite loops, the Bean Validation implementation must
ignore the cascading operation if the associated object instance has
already been validated in the current navigation path (starting from
the root object).
Example 3.8. Object graph limits
#assuming the following object graph
Order -(lines)-> Orderline1
Order -(lines)-> Orderline2
Orderline1 -(order)-> Order
Orderline2 -(order)-> Order
Order -(customer)-> User
Order -(shippingAddress)-> Address1
Order -(billingAddress)-> Address2
Address1 -(inhabitant)-> User
Address2 -(inhabitant)-> User
User -(addresses)-> Address1
User -(addresses)-> Address2
#validation branches are as followed
Order -(lines)-> Orderline1
- order is ignored: Order is already present in the branch
Order -(lines)-> Orderline2
- order is ignored: Order is already present in the branch
Order -(customer)-> User -(addresses)-> Address1
- inhabitant is ignored: User is already present in the branch
Order -(customer)-> User -(addresses)-> Address2
- inhabitant is ignored: User is already present in the branch
Order -(shippingAddress)-> Address1 -(inhabitant)-> User
- addresses to Address1 is ignored: Address1 is already present in
the branch
Order -(shippingAddress)-> Address1 -(inhabitant)-> User -(addresses)-
Address2
- inhabitant is ignored: User is already present in
the branch
Order -(shippingAddress)-> Address2 -(inhabitant)-> User
- addresses to Address2 is ignored: Address2 is already present in
the branch
Order -(shippingAddress)-> Address2 -(inhabitant)-> User -(addresses)-
Address1
- inhabitant is ignored: User is already present in
the branch
Order -(billingAddress)-> Address1 -(inhabitant)-> User
- addresses to Address1 is ignored: Address1 is already present in
the branch
Order -(billingAddress)-> Address1 -(inhabitant)-> User -(addresses)->
Address2
- inhabitant is ignored: User is already present in the branch
Order -(billingAddress)-> Address2 -(inhabitant)-> User
- addresses to Address2 is ignored: Address2 is already present in
the branch
Order -(billingAddress)-> Address2 -(inhabitant)-> User -(addresses)->
Address1
- inhabitant is ignored: User is already present in the branch
The ConstraintViolation objects, built when a failing constraint on an
associated object is found, reflects the path to reach the object from
the root validated object (See Section 4.2, “ConstraintViolation”).
On Feb 19, 2009, at 10:52, Hardy Ferentschik wrote:
5873
days inactive
5881
days old
4 comments
2 participants
participants (2)
-
Emmanuel Bernard -
Hardy Ferentschik