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: Tue, 16 Aug 2005 17:48:20 -0700
On Aug 10, 2005, at 5:37 PM, mmalcolm crawford wrote:
"It is not strictly necessary to model a relationship in both
directions. In some cases it may be useful not to, for example when
a to-many relationship may have a very large number of destination
objects and you are rarely likely to traverse the relationship (you
may want to ensure that you do not unnecessarily fault in a large
number of objects at the destination of a relationship). *If you do
not, however, you may need to do additional work to ensure the
consistency of the object graph. It typically only makes sense to
model a to-one relationship in one direction.*"
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?
Let's call this the case of two different lists of D in the same entity.
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.
Let's call this the case of two different entities having lists of D.
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.
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