Migrating changed objects between contexts
Migrating changed objects between contexts
- Subject: Migrating changed objects between contexts
- From: Jim Thomason <email@hidden>
- Date: Wed, 2 Dec 2009 00:05:50 -0600
I'm stumped and hoping that there's some easy solution that I just
haven't dug up yet. Yes, this is another coredata multithreading
question.
Anyway, in my application the user types in data and fills out forms
and such. It's all tied into CoreData via bindings. Nothing exciting.
But - I've also got a separate thread that wakes up when the data is
changed (via notifications) and updates a graphical representation of
what was typed in. So the user types in the values and my separate
thread reformats it into a graph.
Up until tonight, I'd managed to get away with using the same managed
object context in both threads. I was careful to lock and unlock it in
my second thread, and it seemed to work ok. Unfortunately, I've
expanded the graphing that happens in my second thread, and now I
can't get the thing to run without deadlocking. So I'm looking into
doing it the right way and having one context per thread and handing
around objectIDs to determine what to load. This works fine, as long
as the changes have been saved to the store so my secondary thread
picks them up.
But I don't know a good method to migrate any unsaved changes from one
context to another and that's what I'm looking for. Otherwise, I can
just hand along the IDs and load up my objects to graph them. But I
gotta get those changes moved over.
So. First off, is there some way I can just leave the existing code in
there that uses the same context and just locks it in the secondary
thread? The second thread basically consisted of:
-(void) makeGraph {
NSAutoreleasePool* pool = [[NSAutoreleasePool alloc] init];
[[document managedObjectContext] lock];
//big honkin' code to make the graph
[[document managedObjectContext] unlock];
[pool release];
}
But since both the second thread and the main thread were trying to
load up the same object at once, it deadlocked. Is there some other
bit of locking magic I can add in to do it?
Otherwise, is there some slick, quick easy way to get the changes from
the first context into the second? Presumably, this needs to be done
from the main thread. So I'd create the secondary context in the main
thread (guaranteed not to be used by anyone else), copy the changes
over, then hand it off to the thread. If I tried copying from the main
context in the secondary thread, I assume I could end up with the main
thread trying to access my main context and another deadlock. I'm
somewhat concerned that this could negate my performance gains by
using a separate thread if I just have to do all of this copying and
initialization in my main thread before handing off to the background
one.
However, to do this right I'm going to need to end up writing a lot of
migration code to move from one context to another. I can do it, but
if there's a better way w/o handrolling my own copying routines,
that's clearly what I'd prefer. The added caveat is that I'm still
trying to target Tiger, so none of the whizbang cool coredata features
added to Leopard will help me. If there's a simple method in Leopard
that lets me do it, though, I'll consider abandoning Tiger.
It seems like this would be a common problem with an easy solution.
Otherwise, all the talk about using multiple contexts seems rather
moot if I can't see unsaved changes, am forced to save in advance, or
have to write my own routines to copy the objects myself.
So am I missing some elegant built-in solution that will Just Work for me?
Many thanks,
-Jim....
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden