Re: Core Data & NSPersistentDocument & Concurrency
Re: Core Data & NSPersistentDocument & Concurrency
- Subject: Re: Core Data & NSPersistentDocument & Concurrency
- From: Mike Abdullah <email@hidden>
- Date: Sun, 03 Feb 2013 11:29:39 +0000
On 3 Feb 2013, at 01:04, Eric Gorr <email@hidden> wrote:
>
> On Feb 1, 2013, at 6:59 PM, Mike Abdullah <email@hidden> wrote:
>
>> On 1 Feb 2013, at 20:13, email@hidden wrote:
>>
>>> I've got a NSPersistentDocument. I have read the Concurrency with Core Data in the Core Data Programming Guide and am following the typically recommended approach which is to create separate managed object context (MOC) for each thread, but to share a single persistent store coordinator (PSC)
>>>
>>> I am using a NSOperation which does create its own MOC and does share the PSC with the main thread. The operation adds some objects and I call [MOC save:&error]. This succeeds and a NSManagedObjectContextDidSaveNotification is generated and I get this on the main thread. I then call the mergeChangesFromContextDidSaveNotification method while handling the notification on the main thread. I can see the objects saved in my document.
>>>
>>> The problem then is that my NSPersistentDocument generates an error which says:
>>>
>>> "The document "xxx" could not be saved. The file has been changed by another application"
>>>
>>> Of course, the other application is the NSOperation which did change the document.
>>>
>>> How can I correctly avoid the error?
>>
>> The problem here is you're modifying the document on disk behind NSDocument's back. This has the immediate consequence of changing the modification date. But it also has subtler ramifications from sidestepping NSFileCoordinator and Versions.
>>
>> On OS X 10.7, Core Data offers child contexts. You could setup your background contexts to be children of the main one. This way when they save, they would only be saving back into the main context, without touching the store on disk.
>
> Well, my first problem is that I currently need to support 10.6, but for various reasons I may suggest changing that to 10.7.
On 10.6, your only option is to share the same PSC directly, and update the document's modification date when saving. Happily, 10.6's saving model is a lot simpler than 10.7+
>
>> One downside of that is whenever a child needs to fetch data, it must do so via the main context, blocking the main thread while doing so. Depending on your model, that may prove unacceptable. If so, your better bet is to have a single "root" context with its own private queue. Make the main context a child of it. And then also make any background contexts children of it.
>> At that point, you start to leave NSPersistentDocument's remit. I have code here demonstrating how to do subclass NSDocument directly for this setup:
>
> Interesting solution. Yes, blocking the main thread is not an option for me.
Well bear in mind it should only be a problem if either:
A) you've got fetch requests to execute that take a long time
B) you're executing many requests, one after another
If your uses case is more to do some sort of long-winded processing on a background thread and save the results, then there shouldn't be a problem.
>
> I am a bit surprised that such basic functionality is supported directly somehow.
NSPersistentDocument is old and unloved, is about all it comes down to.
>
>> https://github.com/karelia/BSManagedDocument
>> (make sure you checkout the ksmanageddocument branch!)
>>
>> One great advantage is it leverages the root context to implement asynchronous saves. Out of the box it is designed to match UIManagedDocument's document package layout, but I'm sure you could adjust that. Or perhaps just re-use bits of the code in your NSPersistentDocument subclass.
>
> If I understand this correctly, BSManagedDocument is a complete drop-in replacement for NSPersistentDocument?
No it's a drop-in implementation of UIManagedDocument for OS X. As such it specifically targets creating document packages.
_______________________________________________
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