Question

I’ve recently noticed this strange thing about undo mechanism in Core Data and it’s bothering me ever since.

A quote from NSManagedObjectContext documentation for -undo method:

Sends an undo message to the receiver’s undo manager, asking it to reverse the latest uncommitted changes applied to objects in the object graph.

To reverse the latest uncommitted changes, sounds simple, right?

However, it’s not what is actually happening! Even if I save the context with changes on my managed object, the following -undo call will still successfully reverse the changes. Isn’t it against the thing stated in the docs?

Perhaps I’m doing something wrong? I can post my little testing code if needed. I’m really confused.

Answer 1

You should be confused. The Core Data documentation is a hot mess. They use a lot of words like “uncommitted” in arguably inappropriate ways. They seem to mean objects whose properties isFaulted is equal to NO when they say “uncommitted”.

The Core Data Programming guide goes into more detail:

Change and Undo Management

A context keeps strong references to managed objects that have pending
changes (insertions, deletions, or updates) until the context is sent
a save:, reset , rollback, or dealloc message, or the appropriate
number of undos to undo the change.

The undo manager associated with a context keeps strong references to
any changed managed objects. By default, in OS X the context’s undo
manager keeps an unlimited undo/redo stack. To limit your
application’s memory footprint, you should make sure that you scrub
(using removeAllActions) the context’s undo stack as and when
appropriate. Unless you keep a strong reference to a context’s undo
manager, it is deallocated with its context.

The wording/vocabulary in the documentation is not clear or consistent. I believe the intended usage is that the you should call removeAllActions on the context’s undoManager property when appropriate for your application to avoid unlimited memory growth.