Re: Multiple One-to-One Core Data relationships & inverse
Re: Multiple One-to-One Core Data relationships & inverse
- Subject: Re: Multiple One-to-One Core Data relationships & inverse
- From: Frank Reiff <email@hidden>
- Date: Mon, 10 Sep 2007 10:45:01 +0200
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
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden