Calling mergeChangesFromContextDidSaveNotification: Not Triggering mocObjectsDidChangeNotification in Main Context - ios

This system uses the multi-threaded Core Data configuration of two contexts, shared persistent store.
I have an MOC created on the main thread of type NSMainQueueConcurrencyType (MOC A). There is an observer registered for NSManagedObjectContextObjectsDidChangeNotifications for MOC A.
Elsewhere, on a background thread in a queue, a background MOC (MOC B) of type NSPrivateQueueConcurrencyType and sharing the same PersistentStoreCoordinator as MOC A is created. After some operations, a save is called on MOC B.
An object is observing NSManagedObjectContextDidSaveNotifications on the background MOC B. Upon notification, it calls on the main thread a mergeChangesFromContextDidSaveNotification on MOC A.
Newly inserted and updated objects in MOC B do cause change notifications for observers on MOC A, but deletions in MOC B are not causing these change notifications. A fetch on MOC A does reflect that the deletions in MOC B were propagated to MOC A, but the issue is that there is no change notification. This is worrisome because views and controllers may think deleted objects are still valid.
Any guesses on why this could be happening?
Creation of MOC A
_managedObjectContext = [[NSManagedObjectContext alloc] initWithConcurrencyType:NSMainQueueConcurrencyType];`
Creation of MOC B
NSPersistentStoreCoordinator *psc = [[NSManagedObject managedObjectContext] persistentStoreCoordinator];
dispatch_async(_backgroundQueue, ^{
// create second MOC
NSManagedObjectContext *bgMoc = [[NSManagedObjectContext alloc] initWithConcurrencyType:NSPrivateQueueConcurrencyType];
bgMoc.persistentStoreCoordinator = psc;
bgMoc.undoManager = nil;
[self registerForNotificationWithManagedObjectContext:bgMoc];
});
Notification Handling for NSManagedObjectContextDidSaveNotification
- (void)managedObjectContextObjectsDidSaveNotification:(NSNotification *)notification {
SEL selector = #selector(mergeChangesFromContextDidSaveNotification:);
[[NSManagedObject managedObjectContext] performSelectorOnMainThread:selector
withObject:notification
waitUntilDone:YES];
}
EDIT: I used the recommended SO answer for merging two MOCs from here: https://stackoverflow.com/a/6959868/1505750

Related

iOS/Objective-C: Save to core data in background thread

I am trying to follow this Apple example code for best practice saving to core data in background that includes this code:
NSArray *jsonArray = …; //JSON data to be imported into Core Data
NSManagedObjectContext *moc = …; //Our primary context on the main queue
NSManagedObjectContext *private = [[NSManagedObjectContext alloc] initWithConcurrencyType:NSPrivateQueueConcurrencyType];
[private setParentContext:moc];
My main MOC is save in a property. However, whether I alloc init a fresh MOC or use the one in the property,I get the error:
'Parent NSManagedObjectContext must use either NSPrivateQueueConcurrencyType or NSMainQueueConcurrencyType.'
*** First throw call stack:
The solution to this is said to specify the concurrency type for the MOC as follows:
managedObjectContext = [[NSManagedObjectContext alloc] initWithConcurrencyType:NSMainQueueConcurrencyType];
Should this be done in the main core data stack? Or do you create a new MOC? I tried creating a new MOC and got an error that the MOC was null. It also seems redundant to create a second MOC that with the private one makes three. On the other hand I am afraid to change the main core data stack as it may throw other things off in the app.
What is best way to fix this?
The main MOC should be the child of the background private moc instead of the otherway around. Whenever you save the main moc, the private moc would get updated (thus you need to set the mergePolicy) and then saved to disk. In this scenario you don't need more than 2 mocs.
Because the save will be in the background thread, your code will run smoother in the main thread.
NSManagedObjectContext *moc = [[NSManagedObjectContext alloc] initWithConcurrencyType:NSMainQueueConcurrencyType]; // primary context on the main queue
moc.mergePolicy = NSMergeByPropertyObjectTrumpMergePolicy
NSManagedObjectContext *privateMoc = [[NSManagedObjectContext alloc] initWithConcurrencyType:NSPrivateQueueConcurrencyType];
privateMoc.mergePolicy = NSMergeByPropertyObjectTrumpMergePolicy
[moc setParentContext:privateMoc];

Multicontext Core Data: merging to unsaved context

I'm trying to implement this core data stack:
PSC <--+-- MainMOC
|
+-- BackgroundPrivateMOC
There are some things I'm actually don't understand. Perhaps we have an object in our Persisten Store and we fetch it from the main MOC to do some changes (user change it manually). At the same time my BG MOC is doing some changes with the same one object and save the changes to PS. After the saving is done we must merge the BG MOC to the MAIN MOC (this is a common practice). What I expect after the merging is that the MAIN MOC contains changes from the BG MOC (because the changes were done a bit later than the MAIN ones). But this actually doesn't happened. All I have after the merging is finished is a dirty refreshedObjects = 1 in my MAIN MOC and if I fetch that object again through the MAIN MOC, I don't see any changes made through the BG MOC.
How should I correctly propagate BG changes to MAIN MOC while the
MAIN MOC was not saved prior the BG changes was made?
How to handle
the situation when my MAIN MOC has non-zero refreshedObjects after merging is completed, and
how to push these objects in the MAIN MOC to make them available to
fetch and with?
I believe my sample code can help you to understand my problem more clearly. You can just download the project (https://www.dropbox.com/s/1qr50zto5j4hj40/ThreadedCoreData.zip?dl=0) and run XCTest, that I prepared.
Here is the failing test code:
#implementation ThrdCoreData_Tests
- (void)setUp
{
[super setUp];
/**
OUR SIMPLE STACK:
PSC <--+-- MainMOC
|
+-- BackgroundPrivateMOC
*/
NSPersistentStoreCoordinator *coordinator = [self persistentStoreCoordinator];
// main context (Main queue)
_mainMOC = [[NSManagedObjectContext alloc] initWithConcurrencyType:NSMainQueueConcurrencyType];
[_mainMOC setPersistentStoreCoordinator:coordinator];
[_mainMOC setMergePolicy:NSMergeByPropertyObjectTrumpMergePolicy];
// background context (Private Queue)
_bgMOC = [[NSManagedObjectContext alloc] initWithConcurrencyType:NSPrivateQueueConcurrencyType];
_bgMOC.persistentStoreCoordinator = self.persistentStoreCoordinator;
[[NSNotificationCenter defaultCenter] addObserver:self
selector:#selector(mergeBGChangesToMain:)
name:NSManagedObjectContextDidSaveNotification
object:_bgMOC];
u_int32_t value = arc4random_uniform(3000000000); // simply generate new random values for the test
_mainMOCVlaue = [NSString stringWithFormat:#"%u" , value];
_expectedBGValue = [NSString stringWithFormat:#"%u" , value/2];
Earthquake * mainEq = [Earthquake MR_findFirstInContext:self.mainMOC];
if (!mainEq){ // At the very first time the test is running, create one single test oject.
Earthquake * mainEq = [Earthquake MR_createEntityInContext:self.mainMOC];
mainEq.location = nil; // initial value will be nil
[self.mainMOC MR_saveOnlySelfAndWait];
}
}
- (void)testThatBGMOCSuccessfullyMergesWithMain
{
_expectation = [self expectationWithDescription:#"test finished"];
// lets change our single object in main MOC. I expect that the value will be later overwritten by `_expectedBGValue`
Earthquake * mainEq = [Earthquake MR_findFirstInContext:self.mainMOC];
NSLog(#"\nCurrently stored value:\n%#\nNew main value:\n%#", mainEq.location, _mainMOCVlaue);
mainEq.location = _mainMOCVlaue; // the test will succeed if this line commented
// now change that object in BG MOC by setting `_expectedBGValue`
[_bgMOC performBlockAndWait:^{
Earthquake * bgEq = [Earthquake MR_findFirstInContext:_bgMOC];
bgEq.location = _expectedBGValue;
NSLog(#"\nNew expected value set:\n%#", _expectedBGValue);
[_bgMOC MR_saveToPersistentStoreAndWait]; // this will trigger the `mergeBGChangesToMain` method
}];
[self waitForExpectationsWithTimeout:3 handler:nil];
}
- (void)mergeBGChangesToMain:(NSNotification *)notification {
dispatch_async(dispatch_get_main_queue(), ^{
[self.mainMOC mergeChangesFromContextDidSaveNotification:notification];
// now after merge done, lets find our object with expected value `_expectedBGValue`:
Earthquake * expectedEQ = [Earthquake MR_findFirstByAttribute:#"location" withValue:_expectedBGValue inContext:self.mainMOC];
if (!expectedEQ){
Earthquake * eqFirst = [Earthquake MR_findFirstInContext:self.mainMOC];
NSLog(#"\nCurrent main MOC value is:\n%#\nexptected:\n%#", eqFirst.location, _expectedBGValue);
}
XCTAssert(expectedEQ != nil, #"Expected value not found");
[_expectation fulfill];
});
}
First, when posting core data code, I suggest you not post code that depends on a third party library, unless that third party library is directly related to your problem. I assume MR is magical record, but I don't use it, and it seems to just muddy the waters of the post because who knows what it is (or is not) doing under the covers.
In other words, try to trim examples down to as little as code as necessary... and no more... and only include third-party libraries when absolutely necessary.
Secondly, when writing unit tests for your core data usage, I suggest using an in-memory stack. You always start empty and it can be initialized however you want. Much easier to use for testing.
That said, your problem is a misunderstanding of what mergeChangesFromContextDidSaveNotification does (and does not do).
Basically, you have an object in a Core Data persistent store. You have two different MOCs attached to the store via the same PSC.
Your test then loads the object into main MOC, and changes the value without saving to the PSC. A second MOC then loads the same object, and changes its value to something different (i.e., the store, and both MOCs all have a different value for a particular attribute of the same object).
Now, when we save the MOC, if there are conflicts, the conflicts will be handled as instructed by the mergePolicy. However, the merge policy does not apply to mergeChangesFromContextDidSaveNotification.
You can think of mergeChangesFromContextDidSaveNotification as inserting any new objects, deleting any deleted objects, and "refreshing" any updated objects while preserving any local changes.
In your test, if you add another attribute (e.g., "title") and change both "title" and "location" in the BG MOC but only change "location" in the main MOC, you will see that the "title" gets merged from the BG MOC into the main MOC as expected.
However, as you note in your question, the "location" appears to not get merged. In actuality, it does get merged, but any local change will override what's in the store... and this is exactly what you want to happen because the user likely made that change, and does not want it to be changed behind their back.
Basically, any pending local changes will override changes from the to-be-merged-MOC.
If you want something different, you have to implement that behavior when you do the merge, like this...
- (void)mergeBGChangesToMain:(NSNotification*)note {
NSMutableSet *updatedObjectIDs = [NSMutableSet set];
for (NSManagedObject *obj in [note.userInfo objectForKey:NSUpdatedObjectsKey]) {
[updatedObjectIDs addObject:[obj objectID]];
}
[_mainMOC performBlock:^{
for (NSManagedObject *obj in [_mainMOC updatedObjects]) {
if ([updatedObjectIDs containsObject:obj.objectID]) {
[_mainMOC refreshObject:obj mergeChanges:NO];
}
}
[_mainMOC mergeChangesFromContextDidSaveNotification:note];
}];
}
That code first collects the ObjectIDs of each object that was updated in the merged-from-MOC.
Prior to doing the merge, we then look at each of the updated objects in the merge-to-MOC. If we are merging an object into our MOC, and our merge-to-MOC has also changed that object, then we want to allow the values in the merged-from-MOC to override those in the merged-to-MOC. Thus, we refresh the local object from the store, basically discarding any local changes (there are side effects, e.g., causing the object to become a fault, releasing references to any relationships, and releasing any transient properties - see documentation of refreshObject:mergeChanges:).
Consider the following category, which addresses your situation, and a common problem when using observers like NSFetchedResultsController.
#interface NSManagedObjectContext (WJHMerging)
- (void)mergeChangesIntoContext:(NSManagedObjectContext*)moc
withDidSaveNotification:(NSNotification*)notification
faultUpdatedObjects:(BOOL)faultUpdatedObjects
overrideLocalChanges:(BOOL)overrideLocalChanges
completion:(void(^)())completionBlock;
#end
#implementation NSManagedObjectContext (WJHMerging)
- (void)mergeChangesIntoContext:(NSManagedObjectContext *)moc
withDidSaveNotification:(NSNotification *)notification
faultUpdatedObjects:(BOOL)faultUpdatedObjects
overrideLocalChanges:(BOOL)overrideLocalChanges
completion:(void (^)())completionBlock {
NSAssert(self == notification.object, #"Not called with");
NSSet *updatedObjects = notification.userInfo[NSUpdatedObjectsKey];
NSMutableSet *updatedObjectIDs = nil;
if (overrideLocalChanges || faultUpdatedObjects) {
updatedObjectIDs = [NSMutableSet setWithCapacity:updatedObjects.count];
for (NSManagedObject *obj in updatedObjects) {
[updatedObjectIDs addObject:[obj objectID]];
}
}
[moc performBlock:^{
if (overrideLocalChanges) {
for (NSManagedObject *obj in [moc updatedObjects]) {
if ([updatedObjectIDs containsObject:obj.objectID]) {
[moc refreshObject:obj mergeChanges:NO];
}
}
}
if (faultUpdatedObjects) {
for (NSManagedObjectID *objectID in updatedObjectIDs) {
[[moc objectWithID:objectID] willAccessValueForKey:nil];
}
}
[moc mergeChangesFromContextDidSaveNotification:notification];
if (completionBlock) {
completionBlock();
}
}];
}
#end

cannot add parentContext to NSManagedObjectContext, context already has a coordinator

I have a view where I retrieve a saved Entity (Route *) from the main NSManagedObjectContext. I want to import that into a tempContext. Following Marcus Zarra's examples, I do this:
NSManagedObjectContext *moc = _route.managedObjectContext;
NSManagedObjectID *routeId = [_route objectID];
NSPersistentStoreCoordinator *psc = moc.persistentStoreCoordinator;
self.tempContext = [[NSManagedObjectContext alloc] initWithConcurrencyType:NSPrivateQueueConcurrencyType];
[self.tempContext setPersistentStoreCoordinator:psc];
NSManagedObject *localRoute = [self.tempContext objectWithID:routeId];
[localRoute moToDictionary:localRoute];
self.tempContext.parentContext = moc; // crashes here
Everything is good until I try to set the parentContext of my tempContext to the main MOC. I get the error:
Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Context already has a coordinator; cannot replace.'
I understand it's telling me that I cannot change the persistentStoreCoordinator. However I'm nto sure why it's telling me that. When I set a breakpoint, the tempContext is at a different memory addres than the main moc. Also, the self.tempContext.parentContext is nil. So I'd think if it's nil, I could set the nil parameter to the moc, but it crashes. Any thoughts? Thanks in advance!
For a managed object context, you can
either set the persistent store coordinator, to get a second independent MOC with the
same store,
or set the parent context to get a child MOC,
but not both.

how can child MOC know parent MOC's change?

take this workflow as an example:
NSFetchedResultsController is binded to Main MOC, but Main MOC doesn't do the real save thing, it will propagate to Background Writer MOC, when the latter save to PSC, how can NSFetchedResultsController be notified?
i make a demo to test this, it works, but can't figure out why it works?
demo
Main MOC does not get notified when the data is saved to the persistence store.
However, the only way the data should end up in the background writer MOC is through the temporary background MOC, which goes through the UI MOC. So NSFetchedResultsController gets notified whenever temporary background MOC propagates it data upwards to the UI MOC, and then a separate thread saves it to PSC.
Data is not actually in the sqlite database when NSFetchedResultsController gets notified but it does not have to be.
It is also evident from your save method:
- (void)save
{
[self.mainContext performBlock:^{
NSError *mainContextError;
if(![self.mainContext save:&mainContextError]) {
NSLog(#"main context error:%#", mainContextError);
}
[self.masterContext performBlock:^{
NSLog(#"saving in masterContext");
NSError *masterContextError;
if (![self.masterContext save:&masterContextError]) {
NSLog(#"master context error:%#", masterContextError);
}
}];
}];
}
after [self.mainContext save] is called, NSFetchedResultsController will get notified.

Core Data saving objects in background issue

What I'm trying todo in a nutshell is I am using a background queue to save JSON objects pulled from a web service to the Core Data Sqlite3 database. The saving takes place on a serialized background queue I've created via GCD, and saved to a secondary instance of NSManagedObjectContext that is created for that background queue. Once the save is complete I need to update the instance of NSManagedObjectContext that is on the main thread with the newly created/updated objects. The problem I am having though is the instance of NSManagedObjectContext on the main thread is not able to find the objects that were saved on the background context. Below is a list of actions I'm taking with code samples. Any thoughts on what I'm doing wrong?
Create a background queue via GCD, run all pre-processing logic and then save the background context on that thread:
.
// process in the background queue
dispatch_async(backgroundQueue, ^(void){
if (savedObjectIDs.count > 0) {
[savedObjectIDs removeAllObjects];
}
if (savedObjectClass) {
savedObjectClass = nil;
}
// set the thead name
NSThread *currentThread = [NSThread currentThread];
[currentThread setName:VS_CORE_DATA_MANAGER_BACKGROUND_THREAD_NAME];
// if there is not already a background context, then create one
if (!_backgroundQueueManagedObjectContext) {
NSPersistentStoreCoordinator *coordinator = [self persistentStoreCoordinator];
if (coordinator != nil) {
_backgroundQueueManagedObjectContext = [[NSManagedObjectContext alloc] init];
[_backgroundQueueManagedObjectContext setPersistentStoreCoordinator:coordinator];
}
}
// save the JSON dictionary starting at the upper most level of the key path, and return all created/updated objects in an array
NSArray *objectIds = [self saveJSON:jsonDict objectMapping:objectMapping class:managedObjectClass managedObjectContext:_backgroundQueueManagedObjectContext level:0];
// save the object IDs and the completion block to global variables so we can access them after the save
if (objectIds) {
[savedObjectIDs addObjectsFromArray:objectIds];
}
if (completion) {
saveCompletionBlock = completion;
}
if (managedObjectClass) {
savedObjectClass = managedObjectClass;
}
// save all changes object context
[self saveManagedObjectContext];
});
The "saveManagedObjectContext" method basically looks at which thread is running and saves the appropriate context. I have verified that this method is working correctly so I will not place the code here.
All of this code resides in a singleton, and in the singleton's init method I am adding a listener for the "NSManagedObjectContextDidSaveNotification" and it calls the mergeChangesFromContextDidSaveNotification: method
.
// merge changes from the context did save notification to the main context
- (void)mergeChangesFromContextDidSaveNotification:(NSNotification *)notification
{
NSThread *currentThread = [NSThread currentThread];
if ([currentThread.name isEqual:VS_CORE_DATA_MANAGER_BACKGROUND_THREAD_NAME]) {
// merge changes to the primary context, and wait for the action to complete on the main thread
[_managedObjectContext performSelectorOnMainThread:#selector(mergeChangesFromContextDidSaveNotification:) withObject:notification waitUntilDone:YES];
// on the main thread fetch all new data and call the completion block
dispatch_async(dispatch_get_main_queue(), ^{
// get objects from the database
NSMutableArray *objects = [[NSMutableArray alloc] init];
for (id objectID in savedObjectIDs) {
NSError *error;
id object = [_managedObjectContext existingObjectWithID:objectID error:&error];
if (error) {
[self logError:error];
} else if (object) {
[objects addObject:object];
}
}
// remove all saved object IDs from the array
[savedObjectIDs removeAllObjects];
savedObjectClass = nil;
// call the completion block
//completion(objects);
saveCompletionBlock(objects);
// clear the saved completion block
saveCompletionBlock = nil;
});
}
}
As you can see in the method above I am calling the "mergeChangesFromContextDidSaveNotification:" on the main thread, and I have set the action to wait until done. According to the apple documentation the background thread should wait until that action is complete before it continues with the rest of the code below that call. As I mentioned above once I run this code everything seems to work, but when I try to print out the fetched objects to the console I don't get anything back. It seems that the merge is not in fact taking place, or possibly not finishing before the rest of my code runs. Is there another notification that I should be listening for to ensure that the merge has completed? Or do I need to save the main object context after the merge, but before the fecth?
Also, I apologize for the bad code formatting, but it seems that SO's code tags don't like method definitions.
Thanks guys!
UPDATE:
I've made the changes that were recommended below, but still having the same problem. Below is the updated code I have.
This is the code that invokes the background thread saving processes
// process in the background queue
dispatch_async(backgroundQueue, ^(void){
if (savedObjectIDs.count > 0) {
[savedObjectIDs removeAllObjects];
}
if (savedObjectClass) {
savedObjectClass = nil;
}
// set the thead name
NSThread *currentThread = [NSThread currentThread];
[currentThread setName:VS_CORE_DATA_MANAGER_BACKGROUND_THREAD_NAME];
// if there is not already a background context, then create one
if (!_backgroundQueueManagedObjectContext) {
NSPersistentStoreCoordinator *coordinator = [self persistentStoreCoordinator];
if (coordinator != nil) {
_backgroundQueueManagedObjectContext = [[NSManagedObjectContext alloc] init];
[_backgroundQueueManagedObjectContext setPersistentStoreCoordinator:coordinator];
}
}
// save the JSON dictionary starting at the upper most level of the key path
NSArray *objectIds = [self saveJSON:jsonDict objectMapping:objectMapping class:managedObjectClass managedObjectContext:_backgroundQueueManagedObjectContext level:0];
// save the object IDs and the completion block to global variables so we can access them after the save
if (objectIds) {
[savedObjectIDs addObjectsFromArray:objectIds];
}
if (completion) {
saveCompletionBlock = completion;
}
if (managedObjectClass) {
savedObjectClass = managedObjectClass;
}
// listen for the merge changes from context did save notification
[[NSNotificationCenter defaultCenter] addObserver:self selector:#selector(mergeChangesFromBackground:) name:NSManagedObjectContextDidSaveNotification object:_backgroundQueueManagedObjectContext];
// save all changes object context
[self saveManagedObjectContext];
});
This is the code that is called with by the NSManagedObjectContextDidSaveNotification notification
// merge changes from the context did save notification to the main context
- (void)mergeChangesFromBackground:(NSNotification *)notification
{
// kill the listener
[[NSNotificationCenter defaultCenter] removeObserver:self name:NSManagedObjectContextDidSaveNotification object:_backgroundQueueManagedObjectContext];
NSThread *currentThread = [NSThread currentThread];
// merge changes to the primary context, and wait for the action to complete on the main thread
[[self managedObjectContext] performSelectorOnMainThread:#selector(mergeChangesFromContextDidSaveNotification:) withObject:notification waitUntilDone:YES];
// dispatch the completion block
dispatch_async(dispatch_get_main_queue(), ^{
// get objects from the database
NSMutableArray *objects = [[NSMutableArray alloc] init];
for (id objectID in savedObjectIDs) {
NSError *error;
id object = [[self managedObjectContext] existingObjectWithID:objectID error:&error];
if (error) {
[self logError:error];
} else if (object) {
[objects addObject:object];
}
}
// remove all saved object IDs from the array
[savedObjectIDs removeAllObjects];
savedObjectClass = nil;
// call the completion block
//completion(objects);
saveCompletionBlock(objects);
// clear the saved completion block
saveCompletionBlock = nil;
});
}
UPDATE:
So I found the solution. Turns out that the way I was saving out the object IDs on the background thread and then trying to use them on the main thread to re-fetch them wasn't working out. So I ended up pulling the inserted/updated objects from the userInfo dictionary that is sent with the NSManagedObjectContextDidSaveNotification notification. Below is my updated code that is now working.
As before this code starts the pre-prossesing and saving logic
// process in the background queue
dispatch_async(backgroundQueue, ^(void){
// set the thead name
NSThread *currentThread = [NSThread currentThread];
[currentThread setName:VS_CORE_DATA_MANAGER_BACKGROUND_THREAD_NAME];
[self logMessage:[NSString stringWithFormat:#"(%#) saveJSONObjects:objectMapping:class:completion:", [managedObjectClass description]]];
// if there is not already a background context, then create one
if (!_backgroundQueueManagedObjectContext) {
NSPersistentStoreCoordinator *coordinator = [self persistentStoreCoordinator];
if (coordinator != nil) {
_backgroundQueueManagedObjectContext = [[NSManagedObjectContext alloc] init];
[_backgroundQueueManagedObjectContext setPersistentStoreCoordinator:coordinator];
}
}
// save the JSON dictionary starting at the upper most level of the key path
[self saveJSON:jsonDict objectMapping:objectMapping class:managedObjectClass managedObjectContext:_backgroundQueueManagedObjectContext level:0];
// save the object IDs and the completion block to global variables so we can access them after the save
if (completion) {
saveCompletionBlock = completion;
}
// listen for the merge changes from context did save notification
[[NSNotificationCenter defaultCenter] addObserver:self selector:#selector(mergeChangesFromBackground:) name:NSManagedObjectContextDidSaveNotification object:_backgroundQueueManagedObjectContext];
// save all changes object context
[self saveManagedObjectContext];
});
This is the modified method that handles the NSManagedObjectContextDidSaveNotification
- (void)mergeChangesFromBackground:(NSNotification *)notification
{
// kill the listener
[[NSNotificationCenter defaultCenter] removeObserver:self name:NSManagedObjectContextDidSaveNotification object:_backgroundQueueManagedObjectContext];
// merge changes to the primary context, and wait for the action to complete on the main thread
[[self managedObjectContext] performSelectorOnMainThread:#selector(mergeChangesFromContextDidSaveNotification:) withObject:notification waitUntilDone:YES];
// dispatch the completion block
dispatch_async(dispatch_get_main_queue(), ^{
// pull the objects that were saved from the notification so we can get them on the main thread MOC
NSDictionary *userInfo = [notification userInfo];
NSMutableArray *modifiedObjects = [[NSMutableArray alloc] init];
NSSet *insertedObject = (NSSet *)[userInfo objectForKey:#"inserted"];
NSSet *updatedObject = (NSSet *)[userInfo objectForKey:#"updated"];
if (insertedObject && insertedObject.count > 0) {
[modifiedObjects addObjectsFromArray:[insertedObject allObjects]];
}
if (updatedObject && updatedObject.count > 0) {
[modifiedObjects addObjectsFromArray:[updatedObject allObjects]];
}
NSMutableArray *objects = [[NSMutableArray alloc] init];
// iterate through the updated objects and find them in the main thread MOC
for (NSManagedObject *object in modifiedObjects) {
NSError *error;
NSManagedObject *obj = [[self managedObjectContext] existingObjectWithID:object.objectID error:&error];
if (error) {
[self logError:error];
}
if (obj) {
[objects addObject:obj];
}
}
modifiedObjects = nil;
// call the completion block
saveCompletionBlock(objects);
// clear the saved completion block
saveCompletionBlock = nil;
});
}
I'm going to throw this out there. Stop following the best practices for concurrency listed in the Core Data Programming Guide. Apple has not updated it since adding nested contexts which are MUCH easier to use. This video goes into full detail: https://developer.apple.com/videos/wwdc/2012/?id=214
Setup your primary context to use your main thread (appropriate for handling UI):
NSManagedObjectContext * context = [[NSManagedObjectContext alloc] initWithConcurrencyType:NSMainQueueConcurrencyType];
[context setPersistentStoreCoordinator:yourPSC];
For any object you create that may be doing concurrent operations, create a private queue context to use
NSManagedObjectContext * backgroundContext = [[NSManagedObjectContext alloc] initWithConcurrencyType:NSPrivateQueueConcurrencyType];
[backgroundContext setParentContext:context];
//Use backgroundContext to insert/update...
//Then just save the context, it will automatically sync to your primary context
[backgroundContext save:nil];
The QueueConcurrencyType refers to the queue the context will do it's fetch (save and fetch request) operations on. The NSMainQueueConcurrencyType context does all it's work on the main queue, which makes it appropriate for UI interaction. A NSPrivateQueueConcurrencyType does it on it's own private queue. So when you call save on the backgroundContext, it merges it's private data calling the parentContext using performBlock as appropriate automatically. You don't want to call performBlock on the private queue context in case it happens to be on the main thread which will cause a deadlock.
If you want to get really fancy, You can create a primary context as a private queue concurrency type (which is appropriate for background saving) with a main queue context for just your UI and then child contexts of your main queue context for background operations (like imports).
I see you've worked out an answer that works for you. But I have been having some similar issues and wanted to share my experience and see if it is at all helpful to you or others looking at this situation.
Multi-threaded Core Data stuff is always a little confusing to read, so please excuse me if I misread your code. But it appears that there could be a simpler answer for you.
The core issue you had in the first attempt is that you saved off managed object IDs (supposedly the object identifiers that can be passed between threads) to a global variable for use on the main thread. You did this on a background thread. The problem was that you did this BEFORE saving to the background thread's managed object context. Object IDs are not safe to pass to another thread/context pair prior to a save. They can change when you save. See the warning in the documentation of objectID: NSManagedObject reference
You fixed this by notifying your background thread of the save, and inside that thread, grabbing the now-safe-to-use-because-the-context-has-been-saved object IDs from the notification object. These were passed to the main thread, and the actual changes were also merged into the main thread with the call to mergeChangesFromContextDidSaveNotification. Here's where you might save a step or two.
You are registering to hear the NSManagedObjectContextDidSaveNotification on the background thread. You can register to hear that same notification on the main thread instead. And in that notification you will have the same object IDs that are safe to use on the main thread. The main thread MOC can be safely updated using mergeChangesFromContextDidSaveNotification and the passed notification object, since the method is designed to work this way: mergeChanges docs. Calling your completion block from either thread is now safe as long as you match the moc to the thread the completion block is called on.
So you can do all your main thread updating stuff on the main thread, cleanly separating the threads and avoiding having to pack and repack the updated stuff or doing a double save of the same changes to the persistent store.
To be clear - the Merge that happens is on the managed object contextand its in-memory state - the moc on the main thread is updated to match the one on the background thread, but a new save isn't necessary since you ALREADY saved these changes to the store on the background thread. You have thread safe access to any of those updated objects in the notification object, just as you did when you used it on the background thread.
I hope your solution is working for you and you don't have to re-factor - but wanted to add my thoughts for others who might see this. Please let me know if I've misinterpreted your code and I'll amend.
in your case because your writing to the background moc the notification for mergeChangesFromContextDidSaveNotification will come in on the background moc, not the foreground moc.
so you'll need to register for notifications on the background thread coming to the background moc object.
when you receive that call you can send a message to the main thread moc to mergeChangesFromContextDidSaveNotification.
andrew
update:
here's a sample that should work
//register for this on the background thread
NSNotificationCenter *nc = [NSNotificationCenter defaultCenter];
[nc addObserver:self selector:#selector(mergeChanges:) name:NSManagedObjectContextDidSaveNotification object:backgroundMOC];
- (void)mergeChanges:(NSNotification *)notification {
NSManagedObjectContext *mainThreadMOC = [singleton managedObjectContext];
//this tells the main thread moc to run on the main thread, and merge in the changes there
[mainThreadMOC performSelectorOnMainThread:#selector(mergeChangesFromContextDidSaveNotification:) withObject:notification waitUntilDone:YES];
}

Resources