Re: Core Data SQL store looses data that XML store does not
Re: Core Data SQL store looses data that XML store does not
- Subject: Re: Core Data SQL store looses data that XML store does not
- From: Scott Ellsworth <email@hidden>
- Date: Wed, 10 Aug 2005 12:08:40 -0700
On Aug 10, 2005, at 12:13 AM, mmalcolm crawford wrote:
On Aug 9, 2005, at 11:18 AM, Scott Ellsworth wrote:
My Location entity has six toMany relationships to itself. There
are no reverse relationships set for these, because I rarely care
about the other direction
This is almost certainly the issue.
If you don't specify the reverse relationships, then Core Data
cannot know whether the reverse is intended to be to-one or to-
many, so it defaults to to-one. If (as *appears* to be the case)
you're expecting the relationship to be many-to-many, then you'll
run into problems...
So specifying a reverse relationship is a requirement, if the
relationship is a toMany? Wow - I had not even considered that when
designing my data model. I believe my data model can be fixed - I
have a Move entity with a distance attribute, which would let me get
rid of the several different, and noninvertible, relationships I am
currently using. It would not be unreasonable to a list of all
possible Moves from a World, which _would_ have an inverse relationship.
I believe I was led astray by "It is possible, however, for
relationships to be navigable in only one direction—for there to be
no inverse relationship. If, for example, you are never interested in
finding out from a department object what employees are associated
with it, then you do not have to model that relationship." from the
data modelling guide.
I have filed a doc change request to get some toMany language put in
that document as well. A reference to the source of the quote below
would probably be adequate.
(Since Core Data assumes an unspecified inverse is a to-one, "it
creates a foreign key column in the destination table. If the
destination object can be part of more than one source object's
relationship, this column gets overwritten as source objects are
saved".)
Take-home point: You should always model to-many relationships in
both directions.
Will do!
Filed as bug 4204193.
Actually filed as bug 4204139.
(Curiously, 4204193 was filed by Scott too...)
I have been busy! I have a paper whose abstract and outline I am on
the hook for, and I really would rather code network flow
algorithms. Still, needs must.
Scott _______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden