Question

I have a situation where I must copy one NSManagedObject from the main context into an editing context. It sounds unnecessary to most people as I have seen in similar situations described in Stackoverflow but I looks like I need it.

In my app there are many views in a tab bar and every view handles different information that is related to the other views. I think I need multiple MOCs since the user may jump from tab to tab and leave unsaved changes in some tab but maybe it saves data in some other tab/view so if that happens the changes in the rest of the views are saved without user consent and in the worst case scenario makes the app crash.

For adding new information I got away by using an adding MOC and then merging changes in both MOCs but for editing is not that easy. I saw a similar situation here in Stackoverflow but the app crashes since my data model doesn’t seem to use NSMutableSet for the relationships (I don’t think I have a many-to-many relationship, just one-to-many) I think it can be modified so I can retrieve the relationships as if they were attributes

for (NSString *attr in relationships) {
    [cloned setValue:[source valueForKey:attr] forKey:attr];
}

but I don’t know how to merge the changes of the cloned and original objects. I think I could just delete the object from the main context, then merge both contexts and save changes in the main context but I don’t know if is the right way to do it. I’m also concerned about database integrity since I’m not sure that the inverse relationships will keep the same reference to the cloned object as if it were the original one.

Can some one please enlighten me about this?

Answer 1

Wow, lots of questions and randomness in this one. First, you do not need to add comments to your own question, better to edit the question itself.

Second, you don’t need multiple NSManagedObjectContext instances if you are running a single threaded application. Your entire application can easily run off of a single instance. Multiple contexts are for rare edge cases and multi-threading situations.

By using a single context it will resolve all of your issues with your attempts to clone. However, if you are still wondering how to do a deep copy of a NSManagedObject you can get some guidance from the example code in my book at The Pragmatic Programmers; the source code of which is free to download.

Update

All NSManagedObjectContext instances are “editing ones”. You only need a single context per thread. You can easily ask the context for the non-inserted entities if you want to delete them before a save and you can easily save entities as they are changed. Except for some extreme edge cases you do not need a second context.

Update

You are still creating more work for yourself then you need to. You don’t need to save an object for the view to go away. You can leave as many objects as you want in an unsaved state in the context.

You are going to spend more time debugging dealing a deep copy of objects than it is worth with the design you are describing. If you are going to use more than one context, make sure they are attached to the same NSPersistentStoreCoordinator so that you don’t need to copy the objects around, you can just save the “secondary” context and then catch the save notification in the main context.