Multiple One-to-One Core Data relationships & inverse

  • Hi,

    This is probably a stupid newbie question again, but I can't get my
    head around this..

    The Core Data  documentation makes a big deal about the fact that
    each relationship should have an inverse & the compiler now even
    throws a warning when there isn't an inverse.

    What I don't get is this how this is supposed to work with multiple
    role based one-to-one relationships ("has a").

    Say you have a money transfer entity that takes a debit and a credit
    account.

    You'll have:

    MoneyTransfer:
    creditedAccount one-to-one relationship to Account
    debitedAccount one-to-one relationship to Account

    Now Account should have an inverse relationship for this!?

    The inverse could either go to creditedAccount or debited account,
    but not both..!?

    What am I missing?

    Best regards,

    Frank
  • Le 7 sept. 07 à 14:36, Frank Reiff a écrit :

    > Hi,
    >
    > This is probably a stupid newbie question again, but I can't get my
    > head around this..
    >
    > The Core Data  documentation makes a big deal about the fact that
    > each relationship should have an inverse & the compiler now even
    > throws a warning when there isn't an inverse.
    >
    > What I don't get is this how this is supposed to work with multiple
    > role based one-to-one relationships ("has a").
    >
    > Say you have a money transfer entity that takes a debit and a
    > credit account.
    >
    > You'll have:
    >
    > MoneyTransfer:
    > creditedAccount one-to-one relationship to Account
    > debitedAccount one-to-one relationship to Account
    >
    > Now Account should have an inverse relationship for this!?
    >
    > The inverse could either go to creditedAccount or debited account,
    > but not both..!?
    >
    > What am I missing?
    You are missing that you have not one, but two inverse relationship.
    One for debit and one for credit.

    And the relationship is not one to one relationship, but one to many.
    Each account will have many credit and debit transfers. You can have
    something like :

    MoneyTransfer:        Account :
    creditedAccount <<---> creditTransfers
    debitedAccount  <<---> debitTransfers

    Best regards,

    Fred
  • Dear Fred,

    Thanks for your help.

    I actually chose a bad example. I wanted to simplify the problem and
    thereby changed it..

    What I actually have is 3 "custom hierarchy splitting schemes" at 3
    different levels, so it's

    ApplicationSettings "has a"
    level1
    level2
    level3

    and each level "is a" CustomHierarchySplittingScheme

    While it makes sense for each account to have backlinks to all the
    transactions it participates in, the
    "CustomHierarchySplittingSchemes" don't really need to know, so it
    comes back to a one-to-one relationship.

    If I've understood your explanation correctly, the solution for my
    "multiple" one-to-one relationship would be to add three inverse
    relationships to CustomHierarchySplittingSchemes, i.e.

    CustomHierarchySplittingSchemes:
    inverseforLevel1
    inverseforLevel2
    inverseforLevel3

    which would give me:

    ApplicationSettings:        CustomHierarchySplittingSchemes:
    level1 <---> inverse1
    level2 <---> inverse2
    level3 <---> inverse3

    I realize that one could argue that the "levels" should really be a
    to-many relationship to start with, but there are practical reasons
    for keeping them identifiable like this. The entire model is really
    there to provide a model for Cocoa Bindings and having the
    CustomHierarchySplittingSchemes as three separate one-to-one
    relationships makes sense in this context. Besides I would need an
    indexed list rather than an un-ordered set; something that the SQL
    store can't manage.

    There are several aspects of the solution that I'm far from happy with:

    1) the CustomHierarchySplittingSchemes don't need to know who their
    parent is, so the inverse relationships are only there to satisfy the
    framework
    2) adding a forth relationship from ApplicationSettings to
    CustomHierarchySplittingSchemes will involve changing both entities

    I imagined that Apple's insistence on inverse relationships would be
    matched by some amazing behind-the-scenes mechanism that would allow
    something like:

    ApplicationSettings:        CustomHierarchySplittingSchemes:
    level1 <---> inverse
    level2 <---> inverse
    level3 <---> inverse

    You could then move from ApplicationSettings.level1 to the correct
    CustomHierarchySplittingSchemes and back via the
    ApplicationSettings.inverse relationship. I just couldn't find any
    way to express this in the modeler.. Am I right to think that this is
    not actually possible?

    Thanks again for your help.

    Best regards,

    Frank

    On 7 Sep 2007, at 15:27, Frédéric Testuz wrote:

    > Le 7 sept. 07 à 14:36, Frank Reiff a écrit :
    >
    >> Hi,
    >>
    >> This is probably a stupid newbie question again, but I can't get
    >> my head around this..
    >>
    >> The Core Data  documentation makes a big deal about the fact that
    >> each relationship should have an inverse & the compiler now even
    >> throws a warning when there isn't an inverse.
    >>
    >> What I don't get is this how this is supposed to work with
    >> multiple role based one-to-one relationships ("has a").
    >>
    >> Say you have a money transfer entity that takes a debit and a
    >> credit account.
    >>
    >> You'll have:
    >>
    >> MoneyTransfer:
    >> creditedAccount one-to-one relationship to Account
    >> debitedAccount one-to-one relationship to Account
    >>
    >> Now Account should have an inverse relationship for this!?
    >>
    >> The inverse could either go to creditedAccount or debited account,
    >> but not both..!?
    >>
    >> What am I missing?
    > You are missing that you have not one, but two inverse
    > relationship. One for debit and one for credit.
    >
    > And the relationship is not one to one relationship, but one to
    > many. Each account will have many credit and debit transfers. You
    > can have something like :
    >
    > MoneyTransfer:        Account :
    > creditedAccount <<---> creditTransfers
    > debitedAccount  <<---> debitTransfers
    >
    > Best regards,
    >
    > Fred
previous month september 2007 next month
MTWTFSS
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
Go to today