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: Terrence Talbot <email@hidden>
- Date: Wed, 17 Aug 2005 11:52:29 -0700
On Aug 17, 2005, at 9:29 AM, Terrence Talbot wrote:
On Aug 17, 2005, at 2:25 AM, Jack Nutting wrote:
And if you build a system where a manager can maintain
exactly ONE list of employees who aren't his direct subordinates, one
of the first questions you'll get from one of these manager will be
"great, now how can I make a second list?" To that end, I think you
probably ought to model the "list" as a separate entity. Here's a
rough description of the relationships between these entities, in a
syntax I just made up:
MANAGER
subordinates ->> (EMPLOYEE)
lists ->> (LIST)
EMPLOYEE
myBoss -> (MANAGER)
listMemberships ->> (LIST)
LIST
listMaintainer -> (MANAGER)
listMembers ->> (EMPLOYEE)
"->" is a to-one, "->>" is a to-many. Hopefully that is
understandable. This gives you the possibility for a manager to
maintain multiple lists for whatever they want, calling "setBoss:" on
an employee will give you a predictable result, etc. And most
importantly (to address your original problem), all these
relationships are bidirectional.
Yes, I suppose I could do it this way. It seems like additional
overhead and doesn't feel quite as "natural". Instead of asking for
things like foo.thingsForSale and foo.thingsForRent, or
manager.directReports and manager.interns, I have to ask
manager.list.directReportsList.listMembers. Seems cumbersome.
I just happen to have a special case where I have an object that
will have some X in list A and some X in list B and always be the
owner (the inverse of the relationship) for all objects in either
list until they are deleted from the context. Is a separate List
object really the best way to go?
In this case, since I know the owner will not change and that all X
in both list A and list B should be deleted if the owner is deleted,
it seems that I need to do two things. 1) manually set the "owner" of
X when it is created and added to one of the lists -- no problem; and
2) set the delete rule for the to-many, no inverse relationship to be
Cascade. If I do those two things, it seems to me that I should be
able to maintain referential integrity without interposing another
"lists" table.
A related question, though, and I think this is where I may be
showing problems: will a Save As... of the context to a new file
cause any issues? My concern here being that whatever steps Core Data
takes to "migrate" the data to a new file will miss step 1, above.
It's a bit opaque as to what actually happens when an
NSPersistentDocument is "Save As'd" using whatever mechanism is set
up for you in the default case.
Terrence
_______________________________________________
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