I'm really not an expert on this but I had this situation myself and I chose having one inverse relationship back to every object that could own a picture. I don't like the looks of the model graph and I don't like the waste of memory but it works pretty good in my case. I tried the uber-super-class approach before but I couldn't get Migration and Versioning to work.I can't exactly remember why, but I think the problem was this: The migration system couldn't rebuild (at least not straight-forwardly) a graph where a relationship's target class is an abstract superclass, since it didn't know what concrete subclass the object should be made of. Sure there are ways to solve this but I couldn't do it.
Best, Sebastian On Friday, 07 August, 2009, at 06:23AM, "Gideon King" <gid...@novamind.com> 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. > >Should I just make it a one way relationship and disable the warning >messages? 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. 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. > >Or is there another way to model it so that I can work around this >situation without having this issue? 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. Is >there a workable way to model it so as to have the reverse >relationships? > >Thanks > >Gideon >_______________________________________________ > >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/sebastianmorsch%40mac.com > >This email sent to sebastianmor...@mac.com > > _______________________________________________ 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
