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: Jack Nutting <email@hidden>
- Date: Wed, 17 Aug 2005 11:25:45 +0200
> 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. 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.
> 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.
> Although I seem to be having good luck with this, this thread has
> given me concerns about whether I'm creating problems in the
> datastore that will only become apparent down the line.
>
> I don't think I have atypical cases here but they don't seem to be
> model-able along the lines you suggest. Any advice or better
> strategies here would be greatly appreciated.
Hope this helps,
--
// jack
// http://www.nuthole.com
_______________________________________________
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