Re: Threads and Core Data, bindings results in view corruption
Re: Threads and Core Data, bindings results in view corruption
- Subject: Re: Threads and Core Data, bindings results in view corruption
- From: Jeff LaMarche <email@hidden>
- Date: Mon, 31 Mar 2008 14:47:12 -0400
On Mar 31, 2008, at 2:36 PM, David wrote:
On Mon, Mar 31, 2008 at 2:26 PM, Jeff LaMarche
<email@hidden> wrote:
4) You can, as Ben mentioned, use performSelector:onMainThread: to
actually have the object inserted on the main thread's context. It's
a bit of a pain, but threads are always at least a little painful.
How? Core data says that to use NSManagedObjects between threads you
need to pass an ID and access it from another context. But you don't
even get an ID until you perform a save on the original context. I'm
then back to my original problem where the save itself takes too long.
From what I've read so far, my current thinking is that I need to
give up on Core data. I can easily create my own objects, handle my
own locking or synchronization. I was thinking to still use
NSTreeController bound to my objects.
Its a shame because core data sounds so cool. I love the data
modeling aspects. Nice way to think through the problem even if I
end up not using it.
Well, I don't know exactly what you're doing in your thread, but you
could create a method that that took, for example, a dictionary as an
argument, then when you're ready to insert the object in your thread,
pass that method the values you need having it fire on the main thread
and then create the Core Data entity based on the passed values and
then insert it into the main thread's context. 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. I'm almost certain it's POSSIBLE
to do what you want with Core Data, but it's also altogether possible
that it would be easier or more efficient to go with traditional Obj-c
persistence.
Sorry that I've got no magic bullet for you. :-/
Jeff
_______________________________________________
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