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 09:29:17 -0700
On Aug 17, 2005, at 2:25 AM, Jack Nutting wrote:
Ah, ha. So this thread, overall, seems to make the point that to-many
relationships should always have an inverse relationship. Am I
understanding this point correctly? I think there are two places in
my model where this becomes a problem:
1) What to do in the case of having an entity that needs to keep two
separate lists of the same other entity? To put it in terms of the
documentation's example, if I can, suppose I were modeling a manager
that had a list of direct reports and also a separate list of other
employees to be used for another purpose. Let's also assume, for now,
that any single manager would be the owner of any employee created by
the manager for use in one of the two lists. Let's call these List A
and List B. I can set List A and List B both to be to-many
relationships to Employee. But I can't really set an inverse for
these in the modeler. One cancels the other out.
I am trying to avoid having to put flags into Employee along the
lines of "belongs to List A" or "belongs to List B". If I'm careful
about calling setManager: on Employee whenever I create it or delete
it, what else do I need to do/should I be worried about?
I think you need to think about what you're modelling here a bit more,
and ask yourselves some questions about the relationships you're
proposing. Modelling an inverse relationship between
manager.subordinate and employee.boss is pretty straightforward, but
if you want to model a list of employees to be "used for another
purpose", well... presumbaly EVERY employee is going to have a "boss"
relationship, right? Even if they're on some other boss's "B list",
they're going to have their own boss, so these aren't really mutually
exclusive.
Right, obviously, this is a contrived example. My exact modeling
issues have nothing to do with employees or managers, or even people.
There is, in fact, no other boss, even for those on the B list.
That's why I had added the sentence to assume that any single manager
owns, i.e., is the boss of, anybody on either of the lists. In fact,
they will have no existence outside the domain of the owner that
created them. They'll never be moved to another list, etc.
That said, I do see where you're going...
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?
2) What to do in the case of having multiple entities that might make
use of (instances of) the same other entity? Here I'm not sure I can
construct an Employees example. Bear with me. Imagine that I have
entities B and C that both inherit from the abstract entity A. Both B
and C need to create and own lists of Ds. (D also inherits from A,
but A shouldn't need to know about or have any Ds).
I can create to-many relationships from B to D and from C to D, but I
can't really set the inverse in the modeler. I need the inverse
information when working with D, though, so my solution here was to
create a separate to-one relationship, called container, in D that
points back to A. Since B and C inherit from A, this seems to work
out in practice.
I think a clearer solution is to make a new parent entity for B and C,
which inherits from A. Let's go nuts and call it E. All that E has
is a to-many relationship to D, and D's "container" relationship
should point back to E.
To make this more explicit, let's make an example with named entities.
We start off with your original scenario (I've extended my ad hoc
entity syntax to include inheritance), concretized in the modelling of
people, priests, politicians, and followers:
PERSON
PRIEST (inherits from PERSON)
myFollowers ->> FOLLOWER
POLITICIAN (inherits from PERSON)
myFollowers ->> FOLLOWER
FOLLOWER (inherits from PERSON)
myLeader -> PERSON
As you say, this does "work" since priest and politician inherit from
person, but it gives you a set of relationships that are all one-way,
will look odd to a new pair of eyes looking at your model, and it also
doesn't exclude the possibility of a follower's myLeader relationship
pointing back to another follower (since follower also inherits from
person). So I propose this instead:
PERSON
LEADER (abstract, inherits from PERSON)
myFollowers ->> FOLLOWER
PRIEST (inherits from LEADER)
POLITICIAN (inherits from LEADER)
FOLLOWER (inherits from PERSON)
myLeader -> LEADER
Now, instead of 3 unidirectional relationships (including one from an
entity to its parent!), you've got a single pair of inverse
relationships, and the problems with the previous model are gone.
Yes, I take your point. That is a way to do it, though it again seems
to add complication to a model to merely add a parent entity to hold
a single relationship pointer. Still, I will take this under
advisement and stare at my model some more to make sure I've sussed
out any similar issues. This seems more palatable than the solution
to the first problem since it would be potentially code free.
Thanks
_______________________________________________
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