Question

Recently I started a new app requiring just one store (no document based app). For some time I was quite happy thinking I could finally get rid of throwing around the NSManagedObjectContext… until I wanted to save in the background 🙁

Now I am confused about my own code. For example:

- (void)awakeFromInsert
{
    [super awakeFromInsert];
    [self resetCard];
    self.creationDate = TODAY;
    self.dictionary = [Dictionary activeDictionary];
    NSNotificationCenter *center = [NSNotificationCenter defaultCenter];
    [center postNotificationName:NOTE_NEWCARD object:self];    
}

[Dictionary activeDictionary] is a NSManagedObject static function returning a pointer to a NSManagedObject created in the main thread. That will cause a cross/context error during the background save. Because my program always read from the same store, I thought I could avoid writing this:

[Dictionary activeDictionaryWithContext:...]

I suppose that with MagicalRecord, as long as I work always with the same backend is is possible to avoid passing the context pointer. Which function should I use to get that context?

[NSManagedObjectContext MR_defaultContext]
[NSManagedObjectContext MR_context]
[NSManagedObjectContext MR_contextForCurrentThread]

In the example the object sends itself within a notification, something almost granted to cause more conflicts.

• In the case of the notification should I always send only the objectID?

It seems to me that my objects should issue side effect operations/notifications only if they are running in the main context. However some of those side operations change my object graph creating new instances of other entities.

• Can I safely omit the two problematic function calls I have mentioned if I save with [MagicalRecord MR_saveAll] ?

• Should I assume that the objects of the new background saving context will be an exact copy of the ones in my main thread without calling those extra functions?

Now I am having problems because I never expected awakeFromInsert to run several times for the same object of the same store. I was thinking about something like this:

- (void)awakeFromInsert
{
    [super awakeFromInsert];
    if ([self managedObjectContext] == [NSManagedObjectContext MR_defaultContext]) {
        [self resetCard];
        self.creationDate = TODAY;
        self.dictionary = [Dictionary activeDictionary];
        NSNotificationCenter *center = [NSNotificationCenter defaultCenter];
        [center postNotificationName:NOTE_NEWCARD object:self];    
    }
}

That should make my awakeFromInsert code run only once, but not in the background saving context. I am concerned about losing information if I do so

Answer 1

While you can certainly send your object in a notification that way, I would recommend against that. Remember, even with the new parent-child contexts in CoreData, NSManagedObjects are NOT thread safe. If you create or import objects, you will need to save them prior to using them in another context.

MagicalRecord provides a relatively simple API for background saving:

[MagicalRecord saveInBackgroundWithBlock:^(NSManagedObjectContext *localContext){
    MyEntity *newEntity = [MyEntity MR_createInContext:localContext];

    //perform other entity operations here
}];

This block does all the work for you, without worrying about setting up the NSManagedObjectContext properly.

Another reason you should not pass NSManagedObjects across a notification is that you do not know what thread the notification will be received on. This can potentially lead to a crash, because, again, NSManagedObjects are NOT thread safe.

Another alternative to the notification approach you present is to add an observer to NSManagedObjectContextDidSaveNotification, and merge your changes on that notification. This will fire only after your objects are saved, and are safe for crossing contexts through either the parent-child relationship, or the persistent store (the old way).