On May 9, 2010, at 23:21, Mark Sanvitale wrote: > Now, the question. If the pending changes within my moc includes the > deletion of objects and the to-be-deleted objects include a relationship > property with a "cascade" delete rule then should the pool of objects > returned by an includesPendingChanges = YES fetch include the pending, > directly deleted objects? What about the pending, indirectly deleted objects? > It is my belief that the scratch pad nature of the moc does not extend into > the full reaches of pending deletions.
Let me see if I can get this right... In Core Data, deleting an object means marking it for removal from the persistent store at the next save. So, includesPendingChanges == YES shouldn't fetch deleted objects, ever. That really has nothing to do with the relationships, except that relationships may change as a side effect of the deletion. When you delete an object, it and other objects will (AFAIK) only get removed from in-memory relationships if the applicable delete rules cause that effect. And (AFAIK) the delete rules are only applied when 'processPendingChanges' is invoked, which is normally at the next pass through the run loop, if nothing triggers it earlier (and you can of course call it yourself). In spite of the similarity of the method names, the "pending changes" referred to by this method are changes at the property level, and nothing do to (AFAIK) with the pending changes referred to by 'includesPendingChanges', which are at the object/persistent store level. This means (AFAIK) that your in-memory relationships may contain some deleted objects (those not removed by delete rules) all the way up to the time the MOC is saved. At that point (AFAIK) they are forcibly removed from relationships, though I could well be wrong about that. (They may just be forcibly removed from the relationships as represented within the persistent store.) It also means that fetching objects through a relationship might produce different results from getting objects by following relationships directly, depending when you do it. Finally, just to add to the complexity, if you have a strong pointer to a deleted object, that in-memory instance exists as long as there is a strong reference to it (as long as it's retained, if you're not using GC). I believe that you can can expect the deleted object's properties (attributes and relationships) to be faulted out* (changed to nil values) at some point, though the timing of that behavior may be variable and an implementation detail. All of this reflects my experience with 10.5 Core Data -- I don't know if the 10.6 behavior is any different. * Core Data has (AFAIK) the internal ability to "fault out" specific properties of an object, which is not the same thing as faulting out the object itself. It's a pity the property-level "faulting out" can't be accessed via API, because it would be useful for things like caching schemes for big-memory-use properties. But that's another story. _______________________________________________ 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
