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 (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
