Question

Background

I’ve got the following tree of objects:

Name                       Project       
Users                      nil           
  John                     nil            
    Documents              nil           
      Acme Project         Acme Project    <--- User selects a project
        Proposal.doc       Acme Project  
          12:32-12:33      Acme Project  
          13:11-13:33      Acme Project  
            ...thousands more entries here...

• The user can assign a group to a project. All descendants get set to that project.

• This locks up the main thread so I’m using NSOperations.

• I’m using the Apple approved way of doing this, watching for NSManagedObjectContextDidSaveNotification and merging into the main context.

The Problem

My saves have been failing with the following error:

Failed to process pending changes before save. The context is still dirty after 100 attempts. Typically this recursive dirtying is caused by a bad validation method, -willSave, or notification handler.

What I’ve Tried

I’ve stripped all the complexities of my app away, and made the simplest project I could think of. And the error still occurs. I’ve tried:

• Setting the max number of operations on the queue to 1 or 10.

• Calling refreshObject:mergeChanges: at several points in the NSOperation subclass.

• Setting merge policies on the managed object context.

• Build and Analyze. It comes up empty.

My Question

How do I set relationships in an NSOperation without my app crashing? Surely this can’t be a limitation of Core Data? Can it?

The Code

Download my project: http://synapticmishap.co.uk/CDMTTest1.zip

Main Controller

@implementation JGMainController

-(IBAction)startTest:(id)sender {
    NSManagedObjectContext *imoc = [[NSApp delegate] managedObjectContext];

    JGProject *newProject = [JGProject insertInManagedObjectContext:imoc];
    [newProject setProjectName:@"Project"];
    [imoc save];

        // Make an Operation Queue
    NSOperationQueue *queue = [[NSOperationQueue alloc] init];
    [queue setMaxConcurrentOperationCount:1]; // Also crashes with a higher number here (unsurprisingly)

    NSSet *allTrainingGroupsSet = [imoc fetchAllObjectsForEntityName:@"TrainingGroup"];

    for(JGTrainingGroup *thisTrainingGroup in allTrainingGroupsSet) {
        JGMakeRelationship *makeRelationshipOperation = [[JGMakeRelationship alloc] trainGroup:[thisTrainingGroup objectID] withProject:[newProject objectID]];
        [queue addOperation:makeRelationshipOperation];
        makeRelationshipOperation = nil;
    }
}

    // Called on app launch.
-(void)setupLotsOfTestData {
         // Sets up 10000 groups and one project
}

@end

Make Relationship Operation

@implementation JGMakeRelationshipOperation

-(id)trainGroup:(NSManagedObjectID *)groupObjectID_ withProject:(NSManagedObjectID *)projectObjectID_ {
    appDelegate = [NSApp delegate];
    imoc = [[NSManagedObjectContext alloc] init];
    [imoc setPersistentStoreCoordinator:[appDelegate persistentStoreCoordinator]];
    [imoc setUndoManager:nil];
    [imoc setMergePolicy:NSMergeByPropertyStoreTrumpMergePolicy];

    [[NSNotificationCenter defaultCenter] addObserver:self
                                             selector:@selector(mergeChanges:) 
                                                 name:NSManagedObjectContextDidSaveNotification 
                                               object:imoc];
    groupObjectID = groupObjectID_;
    projectObjectID = projectObjectID_;
    return self;
}

-(void)main {
    JGProject       *project        = (JGProject *)[imoc objectWithID:projectObjectID];
    JGTrainingGroup *trainingGroup = (JGTrainingGroup *)[imoc objectWithID:groupObjectID];
    [project addGroupsAssignedObject:trainingGroup];
    [imoc save];

    trainingGroupObjectIDs = nil;
    projectObjectID = nil;
    project = nil;
    trainingGroup = nil;
}

-(void)mergeChanges:(NSNotification *)notification {
    NSManagedObjectContext *mainContext = [appDelegate managedObjectContext];
    [mainContext performSelectorOnMainThread:@selector(mergeChangesFromContextDidSaveNotification:)
                                  withObject:notification
                               waitUntilDone:YES];  
}

-(void)finalize {
    appDelegate = nil;
    [[NSNotificationCenter defaultCenter] removeObserver:self];
    imoc = nil;
    [super finalize];
}
@end


@implementation NSManagedObjectContext (JGUtilities)

-(BOOL)save {
         // If there's an save error, I throw an exception
}

@end

Data Model

Update 1

I’ve experimented some more, and even without the merge, the exception is still thrown. Just saving the managed object context in another thread after modifying a relationship is enough.

I have a shared persistent store coordinator with the app delegate. I’ve tried making a separate NSPersistentStoreCoordinator for the thread with the same URL as my data store, but Core Data complains.

I’d love to suggestions on how I can make a coordinator for the thread. The core data docs allude to there being a way of doing it, but I can’t see how.

Answer 1

You are crossing the streams (threads in this case) which is very bad in CoreData. Look at it this way:

1. startTest called from a button (is IBAction, assuming button tap) on Main thread
2. Your for loop creates a JGMakeRelationship object using the initializer trainGroup: withProject: (this should be called init, and probably call super, but that’s not causing this issue).
3. You create a new managed object context in the operation, on the Main thread.
4. Now the operation queue calls the operations “main” method from a worker thread (put a breakpoint here and you’ll see it’s not on the main thread).
5. Your app goes boom because you’ve accessed a Managed object Context from a different thread than the one you created it on.

Solution:

Initialize the managed object context in the main method of the operation.