Okay, I finally made some progress. The issue seems to be that the way the
test stack is built bypasses a call to applyObjectLayerDefaults() in
EntityResolver. It is this call that creates the bogus relationships, thus
me not being able to reproduce.
I still haven't managed to create the commit issue I saw before, but I think
this may be related to the problem in CAY-1008, whereby the first found
relationship is used. I could be unlucky and the first found one is the
explicitly mapped one, not the runtime created one, which would cause things
to appear to work fine.
My gut feeling is that the problem is in
ObjRelationship#getReverseRelationship. Particularly, line #191 has the
following check:
if (rel.getTargetEntity() != src)
I think that should probably be some sort of instanceof operation. If
there's an explicit mapping to a subclass, we probably should consider that
good enough and not create a runtime relationship to the base class. I'm
not sure of the full impact that change would make, however.
-- KevinOn 3/15/08 3:15 PM, "Kevin Menard" <kmenar..ervprise.com> wrote:
> Sorry for the delay in this. The test case I thought I had was actually for > CAY-1008, not CAY-1009. I'm having difficulty reproducing this in people > datamap. > > The core issue I think is that if I explicitly map relationships to > subclasses, a runtime relationship is created for the base class. Then I > think the same problem in CAY-1008 kicks in. At this point I'm a bit at a > loss as if the problem is more complicated than that or if my mapping is all > whacked out. > > For what it's worth, I've been trying to reproduce the problem using the > AbstractPerson / CustomerRepresentative => ClientCompany relationship. I > haven't been able to induce the runtime relationship yet.
This archive was generated by hypermail 2.0.0 : Sat Mar 15 2008 - 16:10:40 EDT