Cool. With the new model, it is much more clear what mapping we are
talking about... Here it is for other's reference:
http://svn.apache.org/repos/asf/cayenne/main/trunk/framework/cayenne-jdk1.5-unpublished/src/test/resources/people.map.xml
On Mar 28, 2008, at 4:45 AM, Kevin Menard wrote:
I've also added a patch to CAY-1009 that I think fixes the problem.
If you
get an opportunity, could you please review it?
if (target.isSubentityOf((ObjEntity) rel.getTargetEntity()))
continue;
I am confused about this... 'rel.getTargetEntity()' should be compared
with "src", not "target"? But see below, I am unsure about the patch
in general.
assertEquals(1,
context
.getEntityResolver
().getObjEntity("DirectToSubEntity").getRelationships().size());
I think the assertion above is wrong. "Runtime" relationship from
DirectToSubEntity to BaseEntity is entirely correct, as it completes
the mapping graph created by the user.
So my take on that is that Cayenne correctly detects reverse
relationships, however it is not designed to handle "redundant"
relationships. The criteria of "redundant relationships" are these
(somewhat similar to your patch idea, as you may see):
1. Two or more relationships that are mapped over the same
DbRelationship
2. Doesn't matter whether the relationships are explicit (mapped by
the user) or implicit (added in runtime). Your mapping of
RelatedEntity vs. DirectToSubEntity demonstrates that there is no
difference whether the user or framework added a redundant
relationship, things are still messed up.
3. Sources and/or targets overlap in the inheritance hierarchy (i.e.
if we target two inheritance leaves, I expect things to work ok; if we
target subclass and superclass, these are redundant).
So essentially avoiding runtime relationship creation does not solve
the problem of redundant relationships support (as user can map those
explicitly just as easy). I suggest a validation message instead of
changing 'getReverseRelationship'... or something deeper than that,
like a special redundant relationship handler that is aware of this
scenario.
Andrus
