On 3/29/08 1:33 PM, "Andrus Adamchik" <[EMAIL PROTECTED]> wrote:

> 
> On Mar 29, 2008, at 3:16 PM, Kevin Menard wrote:
> 
>> Essentially, what I'm seeing is that there is not a 1:1 correlation
>> between
>> relationships and their reverses.
> 
> True. A very good point. From what I can tell this may be another way
> to tell what "redundant relationships" are.

I think we may have had a different understanding of what redundant means.
I was thinking internal to Cayenne, not considering relationships mapped by
the user as "redundant", even if they may in fact be.

> In the case described both relationships are equally valid reverse
> relationships. I wouldn't even call the situation ambiguous - it is
> just two clearly defined relationships instead of one like we assumed
> in the past.
> 
> So where do we go from here? There are two ways: we either change the
> API to reflect 1:N natire of reverse relationship (and deal with it
> everywhere throught the framework, e.g by setting multiple reverse
> relationships inside CayenneDataObject, etc.) or disallow redundant
> mapping explicitly. Either way it is a good idea to acknowledge this
> scenario explicitly in some way, so that users know what they are
> dealing with.

Right.  This was what I've been trying to convey since opening the two
issues.  I'm glad we're both on the same page now.

> A lazy person in me votes for the later option. Or maybe not that
> lazy? I always liked my object graph structure to avoid any
> inconsistency (e.g. assume relationship cardinality that DB does not
> enforce) and redundancy (e.g. RelatedEntity double relationships over
> the same set of joins). So mentally I never allowed myself to map
> anything like that, and never felt the need to do so. So maybe we
> shouldn't enable this scenario, complicating the framework
> significantly, just because we can?

Yeap, this is the core of what I was getting at.  One problem I see is that
the autocreated runtime relationships affects the relationship cardinality
and can be a real pain in the neck for the user to debug.  Any error message
would not match what the user has mapped and their non-intuitive naming
would not lend to easy debugging.  Please note I'm talking about runtime
relationships created for base classes, as demonstrated in the test for
CAY-1009.

Another way to consider this is how it would impact the work for vertical
and horizontal inheritance.  Would we need to be able to support 1:N
relationships in that case?  If so, we may as well add
getReverseRelationships() : List<Relationship> now to make that work
simpler.

-- 
Kevin

Reply via email to