Re: svn commit: r637443 - in /cayenne/main/trunk/framework/cayenne-jdk1.5-unpublished/src/test: java/org/apache/cayenne/access/ java/org/apache/cayenne/testdo/inherit/auto/ resources/

From: Kevin Menard (kmenar..ervprise.com)
Date: Sat Mar 15 2008 - 16:13:02 EDT

  • Next message: Andrus Adamchik: "Re: svn commit: r637443 - in /cayenne/main/trunk/framework/cayenne-jdk1.5-unpublished/src/test: java/org/apache/cayenne/access/ java/org/apache/cayenne/testdo/inherit/auto/ resources/"

    Yeah, the example is a little odd, but combined with runtime relationship
    created in CAY-1009 for base types, the situation does come up. A fix of
    CAY-1009 may mitigate the need for this. In which case, we could either
    explicitly disallow it or come up with a better alternative.

    Off-hand, I'm thinking a means of mapped queries that take the qualifier
    into account and cast results to the appropriate type. I suppose this would
    have more performance implications than just maintaining the list locally,
    but it should take care of any data integrity issues without getting too
    ugly.

    On 3/15/08 2:13 PM, "Andrus Adamchik" <andru..bjectstyle.org> wrote:

    >
    > On Mar 15, 2008, at 7:31 PM, kmenar..pache.org wrote:
    >
    >> <obj-relationship name="addresses" source="Employee"
    >> target="Address" db-relationship-path="employeeAddresses"/>
    >> + <obj-relationship name="homeAddresses" source="Employee"
    >> target="HomeAddress" db-relationship-path="employeeAddresses"/>
    >
    > Hmm.... I know for sure I never had such mapping (which explains why
    > the bug is there to begin with). Still formally the mapping is valid,
    > so I guess we'd have to handle it.
    >
    > Andrus
    >



    This archive was generated by hypermail 2.0.0 : Sat Mar 15 2008 - 16:13:35 EDT