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 <ha...@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 > <emman...@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@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
