NSManagedObjectContext confusion

Question

I am learning about CoreData. Obviously, one of the main classes you entouer is NSManagedObjectContext. I am unclear about the exact role of this. From the articles i've read, it seems that you can have multiple NSManagedObjectContexts. Does this mean that NSManagedObjectContext is basically a copy of the backend?

How would this resolve into a consistent backend when there is multiple different copies lying around?

So, 2 questions basically:

Is NSManagedContext a copy of the backend database?

and...

For example, say I make a change in context A and make some other change in context B. Then I call save on A first, then B? will B prevail?

Thanks

Laurenalaurence

Answer 1

The NSManagedObjectContext is not a copy of the backend database. The documentation describes it as a scratch pad

An instance of NSManagedObjectContext represents a single “object space” or scratch pad in an application. Its primary responsibility is to manage a collection of managed objects. These objects form a group of related model objects that represent an internally consistent view of one or more persistent stores. A single managed object instance exists in one and only one context, but multiple copies of an object can exist in different contexts. Thus object uniquing is scoped to a particular context.

The NSManagedObjectContext is just a temporary place to make changes to your managed objects in a transactional way. When you make changes to objects in a context it does not effect the backend database until and if you save the context, and as you know you can have multiple context that you can make changes to which is really important for concurrency.

For question number 2, the answer for who prevails will depend on the merge policy you set for your context and which one is called last which would be B. Here are the merge policies that can be set that will effect the second context to be saved.

NSErrorMergePolicyType
Specifies a policy that causes a save to fail if there are any merge conflicts.

NSMergeByPropertyStoreTrumpMergePolicyType
Specifies a policy that merges conflicts between the persistent store’s version of the object and the current in-memory version, giving priority to external changes.

NSMergeByPropertyObjectTrumpMergePolicyType
Specifies a policy that merges conflicts between the persistent store’s version of the object and the current in-memory version, giving priority to in-memory changes.

NSOverwriteMergePolicyType
Specifies a policy that overwrites state in the persistent store for the changed objects in conflict.

NSRollbackMergePolicyType
Specifies a policy that discards in-memory state changes for objects in conflict.

Skid

"concurrency." link is expired. – Uniplanar

Answer 2

An NSManagedObjectContext is specific representation of your data model. Each context maintains its own state (e.g. context) so changes in one context will not directly affect other contexts. When you work with multiple contexts it is your responsibility to keep them consistent by merging changes when a context saves its changes to the store.

Your question is regarding this process and may also involve merge conflicts. Whenever you save a context its changes are committed to the store and a merge policy is used to resolve conflicts.

When you save a context, it will post various notifications regarding progress. In your case, if [contextA save:&error] succeeds, the context will post the notification NSManagedObjectContextDidSaveNotification. When you have multiple contexts, you typically observe this notification and call:

[contextB mergeChangesFromContextDidSaveNotification:notification];

This will merge the changes saved on contextA into contextB.

EDIT: removed the 'thread-safe' comment. NSManagedObjectContext is not thread safe.

Uruguay