Re: Why is it wrong to have relationships without an inverse in Core Data?
Re: Why is it wrong to have relationships without an inverse in Core Data?
- Subject: Re: Why is it wrong to have relationships without an inverse in Core Data?
- From: Luther Baker <email@hidden>
- Date: Wed, 26 Jun 2013 01:52:32 -0500
Ah. Which part is kludgy?
Parent *parent = ...;
Child *child = ...;
parent.activeChild = child;
Child *child2 = ...;
parent.activeChild = child2;
Child *child3 = ...;
parent.activeChild = child3;
Unless I'm missing something, there is no kludge or workaround with this
approach. The code just works. Its ultra clean and doesn't require whatever
it is you are doing to clean things up. Having to remember to implement
"prepareForDeletion" is a kludge. No?
Remember, the best code is no code at
all<http://www.codinghorror.com/blog/2007/05/the-best-code-is-no-code-at-all.html>
.
Again, I'm late to this discussion and I'm surprised it wasn't brought up
... so maybe there is something else to consider - but on the face of it,
it seems simpler and easier to maintain.
-Luther
PS: As an aside, I'm also curious about a comment you made earlier.
> I have no need for an inverse, why does Core Data?
It seems to me that whether or not you want to explicitly *use* an inverse
relationship is fundamentally different than *identifying* that it exists. Core
Data needs meta information and will likely be able to function better and
more efficiently if you can give it more meta information as opposed to
less - whether or not you actually use or leverage that relationship is
actually different than identifying it and telling Core Data.
For example, If a PROJECT can have only one active TASK at a time ... and a
TASK can only belong to one active PROJECT at a time, then the inverse
relationship exists - whether or not you want to identify or use it, it
still exists. Are you simply opposed to being forced to define that inverse
relationship?
Feels odd that, instead of accurately defining the inverse relationship ...
you instead, decide to implement callback methods to manually implement
cleanup code because, you somehow think that is cleaner than accurately
defining the inverse data relationship and letting Core Data just handled
it for you.
No worries, maybe there is some reason why you can't define the inverse
relationship that I missed or I'm being too pedantic. I feel like I'm
digging too much here! My apologies if that is the case. Sounds like you've
already decided your way forward - I was just curious.
On Wed, Jun 26, 2013 at 1:20 AM, Rick Mann <email@hidden> wrote:
>
> On Jun 25, 2013, at 22:57 , Luther Baker <email@hidden> wrote:
>
> > At the risk of sounding like an idiot for stating the obvious ... why not
> > create a (dummy) inverse relationship (Child.activeParent)? No one says
> you
> > have to use it ... or heck, maybe you want to use it.
> >
> > Parent.children <-------->> Child.parent
> > Parent.activeChild <---------> Child.activeParent
> >
> > I just tested this and it works as expected. IE: setting
> Parent.activeChild
> > to different children between saves cleans up both ends of the
> relationship
> > automatically (each subsequent child's 'activeParent' field was
> > automatically cleared when I set a different child to the
> > Parent.activeChild property).
> >
> > I don't know, maybe I missed something.
>
>
> I think that works, and I've done it before, but I find it very kludgey. I
> think I prefer the one-way-with-prepareForDeletion approach instead.
>
> --
> Rick
>
>
>
>
_______________________________________________
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