Question

Following the iOS5 release notes and WWDC2011 presentation examples, I setup a root managed object context as type NSPrivateQueueConcurrencyType. I have a child context which is of type NSMainQueueConcurrencyType (referred to as the default context).

When I save the child context, then save the root context using the block API: performBlockAndWait:, I expect the operation to by synchronous.

That is, right after this block executes, I should be able to get non-temporary ObjectID‘s for all the objects just inserted all the way to the data store.

However, I instead, get temporary object IDs! It’s as if the performBlockAndWait: degenerates to performBlock: and runs async. But why?

Is this a bug, or am I missing some key assumption?

Here’s some relevant code:

// Setup of the root MOC:
__rootContext = [[NSManagedObjectContext alloc] 
    initWithConcurrencyType:NSPrivateQueueConcurrencyType];
[__rootContext setPersistentStoreCoordinator:[self coordinator]];

// Setup of the child MOC; I use it as the "default" context:
__defaultContext = [[NSManagedObjectContext alloc] 
    initWithConcurrencyType:NSMainQueueConcurrencyType];
[__defaultContext setParentContext:__rootContext];

// Here's the essence of the save operation:
[__defaultContext save:&error]

// Setup a block I can invoke that does the save:
void (^rootContextSaveOperation)(void) = ^{
    NSError *rootContextError = nil;
    BOOL wasRootContextSaveSuccessful = [rootContext save:&rootContextError];
    if (!wasRootContextSaveSuccessful) { 
        NSLog(@"RPDataStore: Error saving root context."); }
    };

// Call perform block and wait with the operation:
[__rootContext performBlockAndWait:rootContextSaveOperation];

// Now when I inspect one of the objects just saved, I have this check in my unit test:
BOOL isTempID = [[user objectID] isTemporaryID];

The problem is, for the “user” object part of the MOC hierarchy just saved from it’s leaf MOC to the root, the “isTempID” flag unfortunately, reveals “YES”.

My expectation was that I could perform a save synchronously to get a permanent Object ID I could use in other contexts.

Are my conceptual expectations of performBlockAndWait: incorrect?

If so, how do I save synchronously with this MOC queue configuration and still get non-temporary ObjectIDs right away?

Answer 1

For whom it might be helpful, my workaround was to build a fetch predicte for the managed object that would uniquely retrieve it.

I execute this fetch against the root managed object context, and then, I reliably get a non-temporary Object ID for managed objects that I did previously save. In my case, I already had managed objects that report back what set of keys can be used in a search, that would uniquely identify them.

The other option, is to obtain permanent Object IDs for all objects in the context before that initial save of the child context. You can then use NSManagedObjectContext’s refreshObject:mergeChanges: to refresh the current reference of a particular object in scope. Now it will reflect changes just saved in a child context.

Obtain permanent object IDs using NSManagedObjectContext’s method obtainPermanentIDsForObjects:error: