Re: CoreData and Threading
Re: CoreData and Threading
- Subject: Re: CoreData and Threading
- From: patrick machielse <email@hidden>
- Date: Mon, 21 Nov 2011 01:49:36 +0100
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
email@hidden
_______________________________________________
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