Re: Threads and Core Data, bindings results in view corruption

FROM : Jeff LaMarche
DATE : Mon Mar 31 20:47:12 2008

On Mar 31, 2008, at 2:36 PM, David wrote:

>
> On Mon, Mar 31, 2008 at 2:26 PM, Jeff LaMarche 
> <<email_removed>> 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