Take the 2-minute tour ×

So, there have been several posts here about importing and saving data from an external data source into Core Data. Apple documents a reasonable pattern for this: "import and save on background thread, merge saved objects to main thread." All fine and good.

I have a related but different problem: the user is modifying data in the UI and main thread, and thus modifies state of some objects in the managed object context (MOC). I would like to save these changes from time to time. What is a good way to do that?

Now, you could say that I could do the same: create a background thread with its own MOC and pass the changed objectID-s there. The catch-22 for me with this is that an object's ID changes when it is saved, and I cannot guarantee the order of things happening. I may end up passing a different objectID into the background thread for the same object, based on whether the object has been previously saved or not, and I don't know if Core Data can resolve this and see that different objectID-s are pointing to the same object and not create duplicates for me. (I could test this, but I'm lazywebbing with this question first.)

One thought I had: I could always do MOC saves on a background thread, and queue them up with operationqueue, so that there is always only one save in progress. I would not create a new MOC, I would just use the same MOC as in main thread. Now, this is not thread safe and when someone modifies the MOC in main thread while it is being saved in background thread, the results will probably be catastrophic. But, minus the thread safety, you can see what kind of solution I'd wish for.

To be clear, the problem I need to fix is that if I just do the save in main thread, it blocks the UI for an unacceptably long period of time, I want to move the save to background thread.

So, questions:

  1. what about the reasoning of an object ID changing during saving, and Core Data being able to resolve them to the same object? Would this be the right way of addressing this problem?
  2. any other good ways of doing this?
share|improve this question
I don't think an object's ID changes during saves. That doesn't sound right to me at all. –  Giao Apr 9 '10 at 17:19
An object has one ID before it is first saved, and another, permanent ID after it is saved, which stays the same. Read CD docs. –  Jaanus Apr 9 '10 at 17:38
add comment

2 Answers

up vote 2 down vote accepted

Simply put, you can't move the save to the background thread. Changes are relative to the NSManagedObjectContext and therefore are invisible to a NSManagedObjectContext on another thread.

I would suggest profiling your saves to find out why they are taking so long. Perhaps make them more frequently or find out what else might be causing the performance issue.

You are using a SQLite store right?


If you are using Binary it is definitely going to be an issue as I believe I mentioned to you before. Binary must be loaded 100% into memory and therefore must also be written 100% out to disk.

share|improve this answer
I am still using the binary store for reasons discussed in another thread (efficient runtime processing as whole store is in memory). This might be a good enough reason to go back to SQLite store. Binary store save performance seems to degrade linearly based on how much info has changed. –  Jaanus Apr 9 '10 at 16:57
add comment

It may not solve all of your troubles, but there is a method -[NSManagedObjectContext obtainPermanentIDsForObjects:error:] that you can use to obtain the permanent ID for a managed object prior to saving it to the store. So that should be helpful in any synchronization you end up doing.

share|improve this answer
Which won't matter because unsaved changes are local to the context that created/loaded the object. –  Marcus S. Zarra Apr 10 '10 at 0:20
add comment

Your Answer


