Introduction
My iOS project ships with a Core Data persistent store weighing some 160MB in SQLite format. There is a ton of grouped information in t
One thought: You might want to create different stores altogether and also different persistent store coordinators for each of the store. And then create different managed object contexts for each of model part. So let us say, I have a model with 3 entities: Student, college and courses. Suppose that I want to store Student and college entities in store1, and Course in Store2, I would have 2 sets of managedObjectContext, pesistent store and persistent cordinator. Now given that we can not have any cross store relatioinships, modification in one context do not effect another context. You dont have to create different models or associate them to stores -etc.
Yes, you may use multiple stores for a single model, but you can't create relationships between objects in different stores. Look for the Cross Store Relationships section in Core Data Programming guide, which says essentially that and recommends using fetched properties if you need to relate an object in one store to an object in another.
The answer is yes. @Caleb points to the right resources, but getting it to work is still quite awkward. I thought I'd place a resumé here:
For two NSPersistentStore
instances to share the same model, you have to add a configuration to your model, which is a string-named subset of the entities:
In the model, to an entity that belongs to the second store, you add a fetched property (NSFetchedPropertyDescription
for googlability). This is somewhat of a very simple stored procedure, and it could look like this:
Then, when you add the stores to your persistent store coordinator, you use the strings for the configuration
argument (more info about the options here):
[persistentStoreCoordinator addPersistentStoreWithType:NSSQLiteStoreType
configuration:@"ModifyInBackground"
URL:storeURL1
options:options
error:&error]
[persistentStoreCoordinator addPersistentStoreWithType:NSSQLiteStoreType
configuration:@"ModifyInMain"
URL:storeURL2
options:options
error:&error]
Finally, when you want to get from the entity in store B to the entity in store A, you trigger the fetched property like you would trigger a fault, just by accessing it.
Note: A fetched property always returns an NSArray, because the predicate you write to establish the link might have multiple results. If you want to get to just one entity, you could place something like this in a wrapper method of your NSManagedObject
subclass:
Wallpaper *recordedWallpaper = [record.wallpaper lastObject];