If you needed to do further work on that entity, like adding
relationships to it, then it would get to be trickier, as you'd
also need to get its managedObjectID back to your thread.
Actually this isn't true. You can add relationships, etc. without
having to pass them around since you will be doing a save at some
point and that will sync everything back to the persistent store.
Then, once you pass the OID of your newly inserted object back to
you main thread you can fetch it from the store and the
relationships you added to it, etc. will be intact.
On 10.5, if you use NSMergeByPropertyObjectTrumpMergePolicy, you can
add and remove objects from relationships in a different MOC on a
background thread and just let the merge policy figure it out.
This even works from another process, if you use an sqlite store.
If you're doing a lot of background operations, you'll want to
familiarize yourself with the MOC's merge policies.
Lastly, I kind of wonder if there might be some way to integrate a
secondary In-Memory store into this setup for use in passing the
objects created by the worker thread back to the main thread, it
seems like it might introduce some more complexity but might also be
worthwhile performance-wise since saving to the SQL store does have
a certain amount of latency due to how it hits the disk
(particularly on Tiger). Any thoughts on this Ben?
Probably less important on 10.5, but yes, you could do this. The
easiest way would be for the background thread to push changes to the
main thread with -performSelectorOnMainThread: ... more aggressively
with NSManagedObjects saved to the in memory store, and "clone" them
over to the sqlite store in larger, coalesced batches.
After saving the "real" one, pass a message to the main thread to
remove the temporary one, and use the real one. You'll want to catch
user edits in the intervening window.