Let me try it: If I don’t set this, then the default value is YES. So when I delete an managed object from the context, the context propagates this immediately to the persistent store so the object is gone?
And when I set this to NO, then objects are deleted from the persistent store only when calling -save?
Is that really true? I mean: If it was true, then the default behavior is that once you call the context to delete an object, the object is gone. Lets assume you’re not using an undo manager. So… gone. Right? No rollback possible? Or can it still be recovered with a rollback?
This controls whether deletes are propagated at the time of a change event i.e. following a
didChange...method call (explicit or synthesized.)To my knowledge this only affects the flags on objects in memory marking them as to be deleted or not. It only affects how the context manages the in-memory objects and not how the context manages on disk deletions. When set to YES, it cause the context to flag the objects as one to be deleted and treat it as removed from the object graph. However, an undo will reverse the flag just as if you had directly deleted the object.
This flag is available because there maybe times when when you need objects to hang around for a while even after a delete or cascade relationship has ended. When NO the context will return the “deleted” object up to the point of the next save.
This is an advanced feature and it is seldom used.