Core Data with in-memory store

Question

I want to use Core Data as a cache for a larger dataset on a database server. Not all data will be in memory.

When thinking about this further 2 questions came to mind:

1. Can faulting (for example for 1-n relationships) be used with the in-memory persistent store, and if so, how do you a catch a fault firing?

2. A Core data managed object context has a staleness interval. Is this also applicable to a in-memory store?

Or should I use a NSAtomicStore for this purpose?

Answer 1

Your first question suggests you misinterpreted the intention of NSInMemoryStore type persistent stores. They are the persistent store part of the Core Data stack. Faulting is something that happens when you bring instances into a managed object context; a fault is created which fires and populates itself from the NSPersistentStoreCoordinator's cache or the underlying persistent store when fired. An in-memory store does not change the faulting relationship. Obviously, it won't really help your problem, however since you'll have to persist all the data to memory. In-memory stores are really appropriate for (1) testing (they're fast) and (2) scratch core data stacks in which you want to use Core Data's object graph management without having to persist anything to disk.

In response to you second question, the answer is YES. The staleness interval applies to the context, not to the persistent store.

So, is Core Data appropriate for caching data from a remote database server? Not really. Although Bill Bumgarner (an Apple engineer) has hinted that it's possible, I've found it much easier in my own code to separate the caching from the Core Data object graph management. It's still very nice to use Core Data to manage an object graph and for ease of binding to a Controller/UI layer(s). So my strategy is pull data from the database server and cache it in my own data structure (the libcache and NSCache in OS X 10.6 might make a very good starting point). Then decide what you want in your object graph and migrate that into a Core Data stack (backed by an in-memory persistent store). You'll have to handle change notification or polling from the database server yourself. When the data from the database changes (or the user query changes, etc.), I just tell all editors to finish editing, then wipe the context and rebuild it from the (possibly) updated cache.