• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Core Data threading again
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Core Data threading again


  • Subject: Re: Core Data threading again
  • From: Aurélien Hugelé <email@hidden>
  • Date: Wed, 01 Mar 2006 18:19:50 +0100


On 1 mars 06, at 17:38, Jeff LaMarche wrote:

On Mar 1, 2006, at 9:17 AM, Aurélien Hugelé wrote:

This is normal. But then what is the point of core data threading ? how can the views reflect the modifications made to objects that are done in another thread ? using refreshObject:mergeChange:/objectWithID: does nothing here, the KVO mechanism can simply not work in another thread.

are we FORCED to do everything except fetches in the main thread ?

The point of threading with Core Data is the same as it is with anything else, and no, we're not forced to do everything on the main thread. What we do have to do is somehow inform the main thread's MOC that there are new, changed, or deleted objects in its store. This is usually done by passing the MO's unique identifier between threads. A given object in a single persistent store will always have the same unique identifier in all MOCs.

Yes i only use objectWithID: to exchange datas between mocs/threads, using the unique identifier in all MOCs
the problem, as you said, is the *inform the main thread's MOC* that there are new/changed/deleted objects in its store. BUT HOW CAN I DO THAT ? there is no method for that!


When a managedObject is inserted in a subthread MOC, the main thread MOC can "see" or "realize" the object with objectWithID, you can even refreshObject:mergeChanges: but this has no effect at all on the fact that this moc has not inserted the object! the array controllers bound to this moc are then not updated!!

Worse, imagine an array controller (main thread) containing the destination objects of a to-many relationship. (the array controller is bound to the managed object to-many relationship via "contentSet").
In a thread, modify the relationship (mutate the result of mutableSetValueForKey:), the KVC/KVO notitifications will have no effect on the array controller because the bound object is not the same (in different MOC, managed objects with the same objectID are not the same instance) plus bindings not in the main thread is problematic.
That's why, in my opinion, we are FORCED to use core data with bindings in the main thread :)




I believe that MacTech is going to be running an article in the March issue (possibly April) that gives some code samples showing how to use threads with Core Data.

great, i simply hope it will be quite advanced tutorial :) background fetching is simply too.. simple!


Any idea ? _______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


References: 
 >Core Data threading again (From: Aurélien Hugelé <email@hidden>)
 >Re: Core Data threading again (From: Jeff LaMarche <email@hidden>)

  • Prev by Date: Re: NSCalendar bug with adding to pre-1919 dates?
  • Next by Date: NSJavaVirtualMachine - how to initialize jvm 1.4+ in cocoa bundle
  • Previous by thread: Re: Core Data threading again
  • Next by thread: AddressBook corruption (2)
  • Index(es):
    • Date
    • Thread