Op 19 nov. 2011, om 05:29 heeft Quincey Morris het volgende geschreven: >> 2 - Through 'NSManagedObjectContextObjectsDidChangeNotification' >> >> The objectIDs of the changed / inserted / deleted objects can be collected >> from this notification and forwarded to the background thread. According to >> Apple: >> >> "You pass the object IDs to thread A [-- my background thread --] by >> sending a suitable message to an object on thread A. Upon receipt, on thread >> A you can refetch the corresponding managed objects." >> >> Here is where I miss information: The context of my background context isn't >> aware of the changes in the main thread context (there was no merge) and >> 'refetch the corresponding managed objects' won't work because the shared >> persistent store wasn't updated (there was no save operation from the main >> context)… > > The MOCs are separate scratch pads. Core Data provides no connection between > their object graphs except via save-dependent synchronization, therefore > there's no Core Data solution to your problem. If you weren't using > NSPersistentDocument, then using Core Data -[save:] would provide a possible > solution, but NSDocument semantics of course prevent you from taking that > approach.
Hmm, not really what I wanted to hear! But it does fit in with my recent experiences with CoreData. I didn't quite realize NSDocument's role, but it makes sense. Regardless, the statement from the documentation quoted above seems simply false to me. >> At the moment I cannot find an acceptable way to merge changes from the main >> thread into the background thread context. Is there a solution for my use >> case? > > It's hard to suggest a solution when the description of your scenario is so > general. (For example, I conclude that the main-thread operations are fairly > lightweight, but the background-thread operations are fairly slow or > intensive. Or not.) In fact, the background thread is an audio (CoreAudio) thread -- with all that implies (high priority, time critical, not really under the app's control). > I'd say it's worth taking some time to ask if Core Data is the correct > technology to use for this. Do the conveniences and performance > characteristics it provides outweigh the impedance mismatch with your > application? > > If you must use Core Data, it's worth taking some time to ask if this > simplistic multi-threaded approach is the best approach. Is there a > single-threaded solution that would work better? Is there a multi-threaded > solution that uses a MOC in one thread only? Because it's audio: alas no to both. > If you must use multiple MOCs in multiple threads, then the simplest solution > may be to invent your own set of notifications (speaking generically, not > implying NSNotification in particular) to send update-property dictionaries > from the main thread to the background thread. (You could probably use a KVO > observer on the main thread, send change-dictionaries to the background > thread, and use KVC on the background thread to apply the changes, thus > automating the process almost completely.) This may sound horrendous, but > could perhaps be easier than it sounds. I'm thinking of creating a light-weight object graph representation (non-managed-object) from my persistent document which contains just the info I need to access (read-only) from the audio thread. I could use the 'NSManagedObjectContextObjectsDidChangeNotification' notification to update or refresh this representation. I think / hope this is a workable solution; my model isn't _that_ complicated. For the moment I do like to hold on to the features gained by using a persistent document architecture, esp. undo. I didn't realize I was in for this much trouble when I decided to use both CoreData and CoreAudio in 1 app… patrick -- Patrick Machielse Hieper Software http://www.hieper.nl i...@hieper.nl _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
