[Core Data] Using In-memory persistent store as cache for remote data store

FROM : Robert Walker
DATE : Fri Apr 27 16:43:53 2007

Hi all,

I've been developing a system, where I plan to use Core Data to 
manage an in-memory data store that will act as a cache for a remote 
data store.  The remote store is a RESTful web service.  I have the 
system working nicely for accessing one level of the object graph, 
but I'm a bit stuck on the best way to handle the associations.

I have a few ideas on how I would like to do this, but I was hoping 
for opinions on which approach to use.  Here are my ideas so far:

1. Somehow receive a notification from Core Data via KVO, before a 
fault fires.  I would then fetch my association and manage the 
association.  I haven't been able to find a notification to do this. 
Is there some sort of [aManagedObject faultWillFire] delegate method 
or a XXFaultWillFireNotification?

2. Provide an "eager loading" system to pre-fetch any associations 
needed by the current view.  This should eliminate the faulting 
entirely, since all objects in the graph would be available as 
realized objects.  In this case I would provide my fetch methods an 
array of key paths representing the associations needed by the view.

3. Not use Core Data at all for caching my objects.  I'm afraid if I 
did this I would loose the automatic support for Cocoa bindings and 
undo management.

Also I'm having an issue with releasing and recreating my in-memory 
store.  I only want to use the in-memory store for bindings and undo 
management.  I would like to reset the entire object graph each time 
a request is sent to the remote application.  I tried to release the 
managed object context, and persistent object stores.

I was hoping the method [self managedObjectContext] would then build 
a new empty in-memory store on the next fetch.  However, once I 
release the context and store I can never fetch objects into the new 
one.  I don't get a crash or any errors just no objects can be 
created into the new empty store.

Thanks,
--
Robert Walker
<email_removed>