Re: bidirectional 1:1, not toDepPK how ?

From: Andrus Adamchik (andru..bjectstyle.org)
Date: Tue Oct 28 2003 - 12:17:13 EST

  • Next message: Adrian: "I canīt get data rows..."

    Hi Arndt,

    Back when I was doing the analysis of what types of relationships we
    should support and how, the case of PK-to-PK one to one turned to be
    the most tricky indeed. With master-detail it is more or less clear.
    Your case (I don't know what to call it, "peer-to-peer" or something)
    was going against the common logic.

    Lets assume there are two tables, e.g. Order and Payment that you've
    mentioned, that are independent, but maybe optionally related based on
    PKs. There is a possibility that you can insert an order and a payment
    independently from each other and not logically related to each other,
    but having the same PK. This will result in a bogus implicit
    relationship. This is all relational logic, nothing Cayenne specific so
    far.

    So my suggestion would be to create the schema with the good old FK in
    one of the tables (you pick which one). This will make the tables
    really independent from each other. Of course this will make it a 1..n
    relationship, but 1:1 logic can be enforced by creating custom Cayenne
    accessor/mutator methods (and optionally - a UNIQUE constraint on FK as
    a safeguard).

    Andrus

    On Oct 28, 2003, at 12:03 PM, Arndt Brenschede wrote:
    > Hi,
    >
    > I don't get it. I am trying to setup
    > a bidirectional 1:1 relationship where
    > both directions use the same join, but
    > the foreign key is NOT part of the
    > primary key, so I cannot set the
    > "toDepPK", and so I get the well
    > known "Some parts of FK are missing in snapshot".
    >
    > Does this mean that this constellation
    > is meaningless, and I have to model
    > the foreign- as part of the primary key?
    >
    > This is relevant for me for relations
    > that are optional, e.g. an order and
    > a payment are assigned to each other,
    > but both can exist unassigned as well.
    > This is not the master<->detail
    > scenario, so the toDepPK is not
    > applicable.
    >
    > thanx for thinking,
    >
    > Arndt



    This archive was generated by hypermail 2.0.0 : Tue Oct 28 2003 - 12:17:20 EST