Re: Core Data inverse relationships
Re: Core Data inverse relationships
- Subject: Re: Core Data inverse relationships
- From: "I. Savant" <email@hidden>
- Date: Fri, 7 Aug 2009 09:45:13 -0400
On Aug 7, 2009, at 9:23 AM, Gideon King wrote:
I have a situation where I don't want to have an inverse
relationship, but coredata seems pretty keen on me having inverse
relationships for all relationships. For example, say I have a
"picture" managed object, which has things like the URL, the
displayed size and rotation and caption. Now I have a person object
that has a picture, a building that has a picture, some equipment
that has a picture. This implies that if I had picture in the model,
it would have to have one relationship to person, one to building,
and one to equipment - etc, for everything that could have a picture.
While *I* wouldn't call this an "edge case", it certainly seems to
be one where Core Data's philosophy is concerned. Yet it's a perfectly
reasonable scenario.
Should I just make it a one way relationship and disable the warning
messages?
In the case you described? Yes. If all these Image-using entities
(Person, Building, Equipment) truly are disparate items that have
nothing in common other than "they can have a relationship to an
image", then I wouldn't worry about it.
If, however, you're building some sort of inventory management
system (where people are considered inventory), then it actually
*does* make sense to have an abstract entity (like "InventoryItem")
since logically they'd have other shared properties / relationships
within the inventory system. Sounds like that's not the case for you.
In my opinion, that warning is just a bit over the top most times
it comes up. In my own designs, it's rare that the warning was
justified. Even then it seemed more like a design-philosophy-nit-pick
than a "no, seriously, you're doing it wrong."
I understand that this would just mean that whenever I delete an
object that has a picture associated with it, then I would just have
to also delete the picture - anything else to be aware of
(especially for things like undo etc)? I guess I would also want to
fault the picture if its owner was turned to a fault.
Yes and yes. Not difficult at all if you specify the deletion rule
for the "image" relationship ("Cascade") for the deletion, slightly
more difficult for the faulting behavior but you appear to understand
it, so I won't waste words on it.
The other thing to consider is you lose the benefits of finding out
"to what item does this Image instance belong?" ... which you may or
may not care about.
So far in the documentation I have just found the recommendation
that you don't have one way relationships, and the very brief
section on unidirectional relationships which isn't clear to me.
That's just it - it's a recommendation. Regarding the
unidirectional relationship section, what's not clear to you? Maybe if
you specified that, the list might be able to clarify things for you
and help you make this decision.
Or is there another way to model it so that I can work around this
situation without having this issue?
Sure.
I guess it would be possible to have an abstract super-class in the
model, which has a picture relationship, but that really doesn't
seem like a tidy approach, especially when you have multiple
situations like this with different relationships, and without
multiple inheritance (thank goodness), you'd probably end up having
a nasty uber-super-class with all the relationships applicable to a
subset of the subclasses - yuck.
That's one way, but as I mentioned above, it only makes sense if
these Image-using entities share more than that in common. If that's
all they have in common, that's not good enough a reason in my opinion
to have them all hang off some abstract entity.
Seems utterly ridiculous to me.
Is there a workable way to model it so as to have the reverse
relationships?
Aside from your initial idea of having a relationship for each
possible Image-using entity, you could have one corresponding Image
entity for each Image-using entity (PersonImage, BuildingImage ...),
all subentities of an abstract Image entity that contains the actual
faulting behavior logic, data-holding property, etc. Only the concrete
subentities hold the relationships.
Though more "verbose", that actually seems less ugly to me than the
abstract super entity for each Image-using entity. But it's still ugly
as hell.
IMO, a unidirectional relationship is clean, elegant, justified,
and RIGHT. :-) Just make sure you take extra care to manage it
properly and you shouldn't have a problem.
--
I.S.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden