Re: Cascade Delete won't delete Department in Apple Sample Code
Re: Cascade Delete won't delete Department in Apple Sample Code
- Subject: Re: Cascade Delete won't delete Department in Apple Sample Code
- From: Jerry Krinock <email@hidden>
- Date: Tue, 23 Jun 2009 16:23:52 -0700
On 2009 Jun 23, at 00:48, Quincey Morris wrote:
The delete rules are really about ownership. Department->Employee
ownership is clear: *the* department owns each of its employees. But
Employee->Department ownership isn't well defined. (If two employees
"own" the same department, who gets to decide when to delete the
department?) Therefore, apparently, the problematic cases (Nullify
and Cascade) are just ignored -- beyond the necessary step of
removing the Employee from the Department's set of related Employees.
So for Cascade it's not so much that Core Data failed to deliver on
a promise to delete the Department, but rather that it never really
promised.
That's beautiful, Quincey. Everything you say is certainly true in
real life. But now step in from the garden and back into computer
science. Cocoa is not real life. Cocoa is an abstract system that is
supposed to behave according to its documentation. The documentation
of the NSDeleteRule simply states:
"NSCascadeDeleteRule. If the object is deleted, the destination object
or objects of this relationship are also deleted."
That's all, chief. There is an "if", but there are no "ands" or
"buts". This statement even goes out of its way to define what
happens in case there is only a singular "object". It's deleted.
Gone. Period. No questions. No prisoners.
So, this one gets a Bug Report. 7000470. (Did the person who filed
7000000 get a free iPod?)
The Nullify case is wrong, too -- nothing in the Department actually
gets set to nil -- but the removal of the pointer from the
relationship set is near enough to fulfillment of a Nullify promise
that it doesn't seem like it didn't work.
Well, what I see happening is that, for the to-many relationship, the
pointer to the employee is removed from the set. Let's look at the
documentation on that one:
"NSNullifyDeleteRule. If the object is deleted, back pointers from
the objects to which it is related are nullified."
Although eyebrows are raised at the on-the-fly invention of the term
"back pointers" (not defined in wikipedia.org), I suppose that "back
pointers ... are nullified" could be loosely interpreted to mean that,
in this case of the inverse relationship being to-many, in the object
at the other end of the relationship, in the set value of the inverse
relationship, the pointer to the deleted object is removed. That does
seem to be what happens. The author traded off some precision for
readability -- probably a good decision. I'll let that one slide.
_______________________________________________
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