I have an interesting problem that I can't seem to find a solution to - I have two managed object contexts, 'main' and 'backing'. 'Main' is created with NSMainQueueConcurrencyType, and 'backing' is created with 'NSPrivateQueueConcurrencyType'. Additionally, 'backing' has been set as the parent of main.
I want to do (potentially expensive) write operations on the backing MOC, and then have those changes (when complete) bubble up to the main context and thus have my UI update due to the usage of an NSFetchedResultsController. My problem is as follows - it appears that after the call to mergeChangesFromContextDidSaveNotification, the deletedObjects property on the main MOC is filled with all of the objects that were deleted in the background operation using the backing queue.
As an example, here's some code.
[appDelegate.backingContext performBlock:^{
NSFetchRequest *fetchRequest = [NSFetchRequest fetchRequestWithEntityName:#"Parent"];
NSArray *objects = [appDelegate.backingContext executeFetchRequest:fetchRequest error:nil];
for(Parent *parent in objects) {
NSMutableOrderedSet *children = [parent mutableOrderedSetValueForKey:#"children"];
for(Child *child in children) {
[appDelegate.backingContext deleteObject:child];
}
[children removeAllObjects];
for(int i=0;i<3;i++) {
Child *child = [NSEntityDescription insertNewObjectForEntityForName:#"Child"
inManagedObjectContext:appDelegate.backingContext];
child.name = [NSString stringWithFormat:#"Child #%i", i];
[children addObject:child];
}
}
[appDelegate.backingContext save:nil];
}];
and on my app delegate
- (void)mergeContextChanges:(NSNotification *)notification {
[self.mainContext performBlock:^{
NSLog(#"Before merge: updates - %i, inserts - %i, deletes - %i",
self.mainContext.updatedObjects.count,
self.mainContext.insertedObjects.count,
self.mainContext.deletedObjects.count);
[self.mainContext mergeChangesFromContextDidSaveNotification:notification];
NSLog(#"After merge: updates - %i, inserts - %i, deletes - %i",
self.mainContext.updatedObjects.count,
self.mainContext.insertedObjects.count,
self.mainContext.deletedObjects.count);
}];
}
Here's what the log says after the changes have been merged -
2013-04-03 00:51:40.476 CoreDataTest[41617:c07] Before merge: updates - 0, inserts - 0, deletes - 0
2013-04-03 00:51:40.477 CoreDataTest[41617:c07] After merge: updates - 0, inserts - 0, deletes - 3
You'll note that the main context reports 3 objects pending for deletion. As far as I can tell, this is incorrect - shouldn't mergeContextChanges: cause the (otherwise completely untouched) context's state to not show pending changes? The point of this method is that the changes have already been committed to the persistent store.
What am I missing here?
The documentation for mergeChangesFromContextDidSaveNotification: says:
This method refreshes any objects which have been updated in the other context, faults in any newly-inserted objects, and invokes deleteObject: on those which have been deleted.
which (as I read it) is consistent with your results.
These objects were probably fetched (prior to their deletion) in the main context.
Since your mainContext parent is the backing, you can commit these changes to the parent context (perform a save on the mainContext).
The save should not take long as it is not committed to the persistent store, only to the parent context.
You can keep these items in the main context until it is saved by another flow in your application.
Your UI will respond to the deletion of these items.
Related
Here is the code snippet of my core data operation . It works fine most of the time. But now when I added core data debugging argument to see if all the core data calls are fine with respect to multithreading Core Data Concurrency Debugging , I see a crash on the line [contexts reset]; .
- (void)readAllModelObjects {
NSFetchRequest * fr = [NSFetchRequest ....]
NSManagedObjectContext * context = [selg getChildContext];
[context performBlockAndWait:^{
NSArray * resultArray = [context executeFetchRequest:fr error: nil ];
NSArray * nonCoreDataModelObjectsArray = [self parseCoreDataObjectsToModel: resultArray];
_memberResultArray = nonCoreDataModelObjectsArray ;
}];
[context reset]; // This is the line it crashes .
}
- (NSManagedObjectContet *)getChildContext {
NSManagedObjectContext * privateContext = [[NSManagedObjectContext alloc] initWithConcurrencyType:NSPrivateQueueConcurrencyType];
privateContext.parentContext = [self mainQueueManagedObjectContext];
return privateContext ;
}
- (NSArray * )parseCoreDataObjectsToModel:(NSArray *)cdObjectsArray {
// creates and initializes the model objects array (non managed object class objects ) from core data objects
// return this array
}
There is only one main queue context attached to persistent store coordinator . This one is used as parent for each child context that is created for a core data operation .
(void)readAllModelObjects is called from a background thread as expected .
I got below error from core data
CoreData`+[NSManagedObjectContext _
_Multithreading_Violation_AllThatIsLeftToUsIsHonor__]:
Any hints / suggestions will definitely help me in figuring out the crash , please help .
When you change values of a managedObject those changes are not saved until the context is saved. Once you save the context, the context either writes to disk or pushes it up to its parent context. This is a way to have a few changes that are all done as one unit - in database speak it would be called a transaction. reset undoes those changes. So just like changing object needs to be done on the correct thread, reset which undoes the changes, needs to be done on the correct thread.
In your case, there is no need to call reset at all because you haven't changed anything to context. The context doesn't have any changes that would be undo by a reset. If you would want to call reset you would have to do inside the performBlockAndWait.
TD;DR : [context reset] is not thread-safe and must be done from the correct thread.
I'm dealing with a strange case. I'm getting some data from a API, transform the response JSON into NSManagedObjects and saving them, all that in a background thread and using a NSPrivateQueueConcurrencyType context whose parent is a NSMainQueueConcurrencyType.
At the same time I'm creating the NSManagedObjects, I'm placing them inside an array to use it in my view controller via a completion block executed on the main therad. Here's a simplified version of what I'm doing.
- (void)getObjectFromAPIWithCompletion:((^)(NSArray *objects, NSError *error))completion
{
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0), ^{
NSManagedObjectContext *backgroundMoc = [[CoreDataStack sharedManager] newChildContextWithConcurrencyType:NSPrivateQueueConcurrencyType];
NSArray *items = [self processToParseResponseFromAPIAndSaveInCoreDataUsingContext:backgroundContext];
[backgroundMoc save:nil];
dispatch_async(dispatch_get_main_queue(), ^{
//Beyond this point, all properties of items are nil or 0 (if integer)
if(completion) completion(items, error);
});
});
}
The weird thing happens inside the completion block. I put a breakpoint on the first line of that block and print the items array on the console. Everything looks fine, with all the items (50 in this case) and their properties are OK.
The problem is when that after that line (where I'm not changing anything on the items array) all objects turn into faults and I'm not getting any data on the properties.
Don't know what is the cause of this rare behaviour. Any idea?
Thanks.
EDIT: Hal's answer put me on the right track so here's what I did to fix this problem. Just before calling the block that will be executed on the main thread I "move" the managed objects from the background context to the main context, fetching with their objectIDs. Like this:
NSArray *objects = //Objects created on background thread with Private queue
NSMutableArray *objectsIDs = [NSMutableArray array];
for (Object *object in object) {
[objectsIDs addObject:object.objectID];
}
//Save on private managed object context and on completion...
[self.managedObjectContext saveWithCompletion:^(NSError *error) {
NSManagedObjectContext *mainMOC = [[CoreDataManager sharedManager] mainContext];
NSMutableArray *fetchedObjects = [NSMutableArray array];
for (NSManagedObjectID *objectID in objectsIDs) {
[fetchedArticles addObject:[mainMOC objectWithID:objectID]];
}
if (completion) completion(fetchedObjects, pagination, nil);
}];
This way, all objects are not faults on the main thread.
If those objects (the contents of items) have been created on the background thread, you can't use them in the main thread. You can't pass NSManagedObject instances between threads.
You'll have to pass NSManagedObjectIDs (which won't be permanent until you've saved the background MOC), or use an NSFetchedResultsController (pointing to the main MOC) on the main thread. This is one of the cases that NSFetchedResultsController was designed for, so I recommend you go that route.
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
I'm trying to separate my application work when there is a bigger work to do to optimize performance. My problem is about a NSManagedObjectContext used in another thread than the main one.
I'm calling:
[NSThread detachNewThreadSelector:#selector(test:) toTarget:self withObject:myObject];
On the test method there are some stuff to do and I have a problem here:
NSArray *fetchResults = [moc
executeFetchRequest:request
error:&error];
Here is my test method:
-(void) test:(MyObject *)myObject{
#autoreleasepool {
//Mycode
}
}
The second time I call the test method, my new thread is blocked when the executeFetchRequest is called.
This problem arrived when my test method is called more than one time in succession. I think the problem comes from the moc but I can't really understand why.
Edit:
With #Charlie's method it's almost working. Here is my code to save my NSManagedObjectContext (object created on my new thread).
- (void) saveContext:(NSManagedObjectContext *) moc{
NSError *error = nil;
if ([moc hasChanges] && ![moc save:&error]) {
NSLog(#"Unresolved error %#, %#", error, [error userInfo]);
}
}
This method is called on the new thread. My problem now is that with this save, I have a deadlock and I don't really understand why. Without it's perfectly working.
Edit2
I'm working on this issue but I still can't fix it. I changed my code about the detachNewThreadSelector. Here is my new code:
NSManagedObjectContext* context = [[NSManagedObjectContext alloc]
initWithConcurrencyType:NSPrivateQueueConcurrencyType];
context.persistentStoreCoordinator = self.persistentStoreCoordinator;
context.undoManager = nil;
[context performBlock:^
{
CCImages* cachedImage;
NSManagedObjectContext *childContext = [[NSManagedObjectContext alloc] initWithConcurrencyType:NSPrivateQueueConcurrencyType];
childContext.parentContext = context;
cachedImage=[CCImages getCCImageForKey:path inManagedObjectContext:childContext];
UIImage *image = [self getImageFromCacheWithPath:path andCachedImage:cachedImage atDate:now];
if (image != nil){
if(![weakSelf.delegate respondsToSelector:#selector(CacheCacheDidLoadImageFromCache:)])
[weakSelf setDelegate:appDelegate.callbacksCollector];
//[weakSelf useCallbackCollectorForDelegate:weakSelf inMethod:#"initPaginatorForListMoments"];
[weakSelf.delegate CacheCacheDidLoadImageFromCache:image];
}
}
- (UIImage*) getImageFromCacheWithPath:(NSString*) path andCachedImage:(CCImages *) cachedImage atDate: (NSDate *) now{
NSURL* localURL=[NSURL URLWithString:cachedImage.path relativeToURL:[self imageCacheDirectory]];
UIImage * image;
//restore uiimage from local file system
if (localURL) {
image=[UIImage imageWithContentsOfFile:[localURL path]];
//update cache
[cachedImage setLastAccessedAt:now];
[self saveContext];
if(image)
return image;
}
return nil;
}
Just after that, I'm saving my contexts (manually for now)
[childContext performBlock:^{
NSError *error = nil;
if (![childContext save:&error]) {
DDLogError(#"Error during context saving when getting image from cache : %#",[error description]);
}
else{
[context performBlock:^{
NSError *error = nil;
if (![context save:&error]) {
DDLogError(#"Error during context saving when getting image from cache : %#",[error description]);
}
}];
}
}];
There is a strange problem. My call back method is called without any problem on my controller (which implements the CacheCacheDidLoadImageFromCache: method). On this method I attest the reception of the image (DDLogInfo) and say that I want my spinner to stop. It does not directly but only 15secondes after the callback method was called.
My main problem is that my context (I guess) is still loading my image from the cache while it was already found. I said 'already' because the callback method has been called and the image was present. There is no suspicious activity of the CPU or of the memory. Instruments didn't find any leak.
I'm pretty sure that I'm using wrongly the NSManagedObjectContext but I can't find where.
You are using the old concurrency model of thread confinement, and violating it's rules (as described in the Core Data Concurrency Guide, which has not been updated yet for queue confinement). Specifically, you are trying to use an NSManagedObjectContext or NSManagedObject between multiple threads.
This is bad.
Thread confinement should not be used for new code, only to maintain the compatibility of old code while it's being migrated to queue confinement. This does not seem to apply to you.
To use queue confinement to solve your problem, first you should create a context attached to your persistent store coordinator. This will serve as the parent for all other contexts:
+ (NSManagedObjectContent *) parentContextWithPersistentStoreCoordinator:(NSPersistentStoreCoordinator *)coordinator {
NSManagedObjectContext *result = nil;
result = [[NSManagedObjectContext alloc] initWithConcurrencyType:NSPrivateQueueConcurrencyType];
[result setPersistentStoreCoordinator:coordinator];
return result;
}
Next, you want the ability to create child managed object contexts. You will use these to perform work on the data, wether reading or writing. An NSManagedObjectContext is a scratchpad of the work you are doing. You can think of it as a transaction. For example, if you're updating the store from a detail view controller you would create a new child context. Or if you were performing a multi-step import of a large data set, you would create a child for each step.
This will create a new child context from a parent:
+ (NSManagedObjectContext *) childContextWithParent:(NSManagedObjectContext *)parent {
NSManagedObjectContext *result = nil;
result = [[NSManagedObjectContext alloc] initWithConcurrencyType:NSPrivateQueueConcurrencyType];
[result setParent:parent];
return result;
}
Now you have a parent context, and you can create child contexts to perform work. To perform work on a context, you must wrap that work in performBlock: to execute it on the context's queue. I do not recommend using performBlockAndWait:. That is intended only for re-rentrant methods, and does not provide an autorelease pool or processing of user events (user events are what drives nearly all of Core Data, so they're important. performBlockAndWait: is an easy way to introduce bugs).
Instead of performBlockAndWait: for your example above, create a method that takes a block to process the results of your fetch. The fetch, and the block, will run from the context's queue - the threading is done for you by Core Data:
- (void) doThingWithFetchResults:(void (^)(NSArray *results, NSError *error))resultsHandler{
if (resultsHandler != nil){
[[self context] performBlock:^{
NSArray *fetchResults = [[self context] executeFetchRequest:request error:&error];
resultsHandler(fetchResults, error);
}];
}
}
Which you would call like this:
[self doThingsWithFetchResults:^(NSArray *something, NSError *error){
if ([something count] > 0){
// Do stuff with your array of managed objects
} else {
// Handle the error
}
}];
That said, always prefer using an NSFetchedResultsController over using executeFetch:. There seems to be a belief that NSFetchedResultsController is for powering table views or that it can only be used from the main thread or queue. This is not true. A fetched results controller can be used with a private queue context as shown above, it does not require a main queue context. The delegate callbacks the fetched results controller emits will come from whatever queue it's context is using, so UIKit calls need to be made on the main queue inside your delegate method implementations. The one issue with using a fetched results controller this way is that caching does not work due to a bug.
Again, always prefer the higher level NSFetchedResultsController to executeFetch:.
When you save a context using queue confinement you are only saving that context, and the save will push the changes in that context to it's parent. To save to the store you must recursively save all the way. This is easy to do. Save the current context, then call save on the parent as well. Doing this recursively will save all the way to the store - the context that has no parent context.
Example:
- (void) saveContextAllTheWayBaby:(NSManagedObjectContext *)context {
[context performBlock:^{
NSError *error = nil;
if (![context save:&error]){
// Handle the error appropriately.
} else {
[self saveContextAllTheWayBaby:[context parentContext]];
}
}];
}
You do not, and should not, use merge notifications and mergeChangesFromContextDidSaveNotification: with queue confinement. mergeChangesFromContextDidSaveNotification: is a mechanism for the thread confinement model that is replaced by the parent-child context model. Using it can cause a whole slew of problems.
Following the examples above you should be able to abandon thread confinement and all of the issues that come with it. The problems you are seeing with your current implementation are only the tip of the iceberg.
There are a number of Core Data sessions from the past several years of WWDC that may also be of help. The 2012 WWDC Session "Core Data Best Practices" should be of particular interest.
if you want to use managed object context in background thread, there are two approaches,
1 Create a new context set concurrency type to NSPrivateQueueConcurrencyType and set the parentContext to main thread context
2 Create a new context set concurrency type to NSPrivateQueueConcurrencyType and set persistentStoreCoordinator to main thread persistentStoreCoordinator
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^(void) {
NSManagedObjectContext *privateContext = [[NSManagedObjectContext alloc] initWithConcurrencyType:NSPrivateQueueConcurrencyType];
privateContext.persistentStoreCoordinator = mainManagedObjectContext.persistentStoreCoordinator;
[[NSNotificationCenter defaultCenter] addObserverForName:NSManagedObjectContextDidSaveNotification object:nil queue:nil usingBlock:^(NSNotification* note) {
NSManagedObjectContext *moc = mainManagedObjectContext;
if (note.object != moc) {
[moc mergeChangesFromContextDidSaveNotification:note];
}
}];
// do work here
// remember managed object is not thread save, so you need to reload the object in private context
});
before exist the thread, make sure remove the observer, bad thing can happen if you don't
for more details read http://www.objc.io/issue-2/common-background-practices.html
Overview: I have a refresh process that runs in the background (just using performInBackground is all) and part of that has db updates so I have a separate MOC for the background thread. I then use the didSave notification to merge in the changes, but I'm not see those updates in the DB/my UI. I've logged the object itself before and after the save and I can see the attribute is changed, but in the method called by notification, I log the objects in the context received and it doesnt have updated value. I know some other things are probably ugly, but just trying to figure out this core data piece. I previously had just one MOC and things worked (non core data should be fine), but I've rearchitected things to be in background now and wanted to use guidance of a separate MOC.
Create context, setup notification, set attribute and save. Post save, the value is 0
// this creates context with same PSC as main MOC
NSManagedObjectContext *context = [[MyAppDelegate application] temporaryContext];
[[NSNotificationCenter defaultCenter] addObserver:(MyAppDelegate *)[[UIApplication sharedApplication] delegate]
selector:#selector(managedObjectContextDidSave:)
name:NSManagedObjectContextDidSaveNotification
object:context];
NSLog(#"value is %d", [[myObject email] boolValue]); //value is 1
[myObject setEmail:[NSNumber numberWithBool:![[myObject email] boolValue]]];
NSError *error;
if (![context save:&error]) {
NSLog(#"Error in saving BriefCase object - error:%#" ,error);
}
NSLog(#"value is %d", [[myObject email] boolValue]); //value is 0 now
Here, I check the MOC I was sent and i see all values are 1. So when merge happens, no updates made. Where is the disconnect if I saw the object had a 0 after saving?
// Called when a ManagedObjectContext performs save operation
- (void)managedObjectContextDidSave:(NSNotification *)notification {
NSManagedObjectContext *receivedMOC = [notification object];
NSArray *items = [MyObjectClass getAllMyObjectsInManagedObjectContext:receivedMOC];
for (int i=0; i < [items count]; i++) {
NSLog(#"value is %d", [[[items objectAtIndex:i] email] boolValue]);
}
add'l context creation code, may be the issue
- (NSManagedObjectContext *)temporaryContext {
NSManagedObjectContext *newContext = [[[NSManagedObjectContext alloc] init] autorelease];
NSPersistentStoreCoordinator *psc = [self.managedObjectContext persistentStoreCoordinator];
[newContext setUndoManager:nil];
[newContext setPersistentStoreCoordinator:psc];
return newContext;
The temporaryContext creates a new MOC on each call, so is seems that you actually work with 2 different background MOCs. myModel is created on a MOC that is different from
NSManagedObjectContext *context = [[MyAppDelegate application] temporaryContext];
and therefore saving the latter has no effect on the changes in myModel.
You have to modify your code such that only one temporary context is created and passed around.
I don't see you calling
[mainMOC mergeChangesFromContextDidSaveNotification:saveNotification];
when handling the notification. This might explain what is happening. This should be called on the main thread.