Re: Core Data, NSURLProtocol and Threads - A Case of Missing Managed Objects
Re: Core Data, NSURLProtocol and Threads - A Case of Missing Managed Objects
- Subject: Re: Core Data, NSURLProtocol and Threads - A Case of Missing Managed Objects
- From: Mike Abdullah <email@hidden>
- Date: Thu, 7 Feb 2008 00:35:40 +0000
On 6 Feb 2008, at 00:25, Philip Dow wrote:
Hi all,
I have a complex situation that I'll try to explain correctly. I'm
using my own url protocol to load image data from an in memory store
into a webkit web view. When an image is dropped onto the web view I
intercept it, grab the tiff data, write the data to a new managed
object and substitue my own html string with the correct img src
information.
Almost instantaneously the webview informs its delegate that it has
received a url request. I substitute my own url request and in the
url protocol subclass ensure that it will have the responsibility
for loading it. It does, and the url protocol subclass calls back to
the document object to grab the image data using a special
identifier I am encoding in my own url.
That callback happens on a separate thread, so I create a second
manage object context from the document's persistent store and use a
fetch with a predicate attached to grab the sought image data's
managed object -- the fetch request uses the unique id encoded into
the url, which the protocol subclass is passing in the callback. If
I find the object, I grab the image data from it and return that
back to the protocol subclass.
It's hard to believe this is all possible, but sure enough!
Everything works but with a caveat. In the second thread as the url
protocol is loading and calling back to the document to grab the
image data, my fetch request on the second object context does not
return the object until I actually save the document.
This means that immediately after the drop, the fetch doesn't see
the object I just created in the first context, but as soon as I
save the document and reload the webview, it does. Reloading the web
view without saving the context does not suffice.
I've tried calling commitEditing, processPendingChanges and
refreshObject:mergeChanges on the two contexts but nothing seems to
work. How can I ensure that the second context on the second thread
sees the object just created by the first context in the first thread?
As you've already stated, the context needs to saved. Sadly, this is
the only proper way at present to propagate that change back through
the PSC and into the first MOC. As an alternative though, you could
perhaps pick up the change notification from the 2nd context and use
it to modify the 1st context to match. Then you have to ensure the 2nd
context is never actually saved, and makes sure it loads its content
from disk in the case of a conflict.
Mike.
Thanks,
~Phil
_______________________________________________
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
_______________________________________________
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