extent of the "scratch pad" nature of a Core Data managed object context
extent of the "scratch pad" nature of a Core Data managed object context
- Subject: extent of the "scratch pad" nature of a Core Data managed object context
- From: Mark Sanvitale <email@hidden>
- Date: Sun, 9 May 2010 23:21:17 -0700
- Old-return-path: email@hidden
Curious if anyone can confirm or deny a behavior of Core Data's managed object context. I understand that there is the committed/real-deal state of an on-disk, persistent store, and there is a managed object context (moc) that is described as a "scratch pad" that builds up modifications to the on-disk state and which can then be either committed or discarded. This is cool. Furthermore, the moc can be searched via a "fetch request", and I can control how a fetch treats proposed but uncommitted changes via the setIncludesPendingChanges method.
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.
Thanks in advance.
Mark Sanvitale
Real Networks_______________________________________________
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