[hibernate-dev] HV: Considering static vs. runtime type for property path creation

Gunnar Morling gunnar.morling at googlemail.com
Thu Apr 21 17:11:50 EDT 2011


Hi,

> The good news is that we would have to move and modify only one single line
> to make this happen :-)

That sounds great. So we could even deliver this with HV 4.2.

I created http://opensource.atlassian.com/projects/hibernate/browse/BVAL-226
in order to have the intended behavior clarified in the BV 1.1 spec.

--Gunnar


2011/4/21 Hardy Ferentschik <hardy at hibernate.org>:
> Hi,
>
> same here. I don't have really have a strong opinion, but the argument
> that constraints are determined based on the runtime type seems reasonable.
>
> The good news is that we would have to move and modify only one single line
> to make this happen :-)
> I created a test locally and w/ a small change in
> ValidatorImpl.validateCascadedConstraints
> we would get the result we want.
>
> I created HV-468
>
> --Hardy
>
>
> On Thu, 21 Apr 2011 10:04:19 +0200, Emmanuel Bernard
> <emmanuel at hibernate.org> wrote:
>
>> I don't have any strong opinion.
>> I'd be tempted to say you are right. It seems to be somebody expecting a
>> non indexable path would not be hurt if the Path structure returned an
>> indexable version. Can you also create a BVAL issue so that the spec
>> gets clarified.
>>
>> On 21 avr. 2011, at 00:11, Gunnar Morling wrote:
>>
>>> Hi guys,
>>>
>>> there was an interesting question on the Validator forum
>>> (https://forum.hibernate.org/viewtopic.php?f=9&t=1010626&start=0)
>>> which IMO boils down to the question whether the static or the runtime
>>> type of an association should be considered when creating property
>>> paths in case of cascading validations.
>>>
>>> An example:
>>>
>>> class Foo {
>>>
>>>    private Collection<Bar> bar1 = new ArrayList<Bar>();
>>>
>>>    private List<Bar> bar2 = new ArrayList<Bar>();
>>>
>>> }
>>>
>>> When validating an instance of Foo (which has invalid elements in
>>> bar1/bar2) with HV, the resulting property path node for bar1 would be
>>> iterable but not indexable ("bar1[]"), while the property path node
>>> for bar2 would be iterable and indexable ("bar2[123]"). This is that
>>> way because the static type of bar1/bar2 (Collection vs. List) is
>>> considered when building the nodes, and not the runtime type
>>> (ArrayList in both cases).
>>>
>>> That said, basing the path on the runtime type instead would seem
>>> reasonable to me, too (as for instance the constraints to validate are
>>> also determined based on the runtime type of references). I scanned
>>> through the BV spec. (section 4.5) but didn't find a clear answer
>>> which approach should be followed. Are there any opinions on that?
>>>
>>> Thanks,
>>>
>>> Gunnar
>>
>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>




More information about the hibernate-dev mailing list