Core Data store atomicity with multiple stores

Question

Core Data allows you to add multiple persistent stores to a single NSPersistentStoreCoordinator (each with a different configuration) name, thereby bringing them together in a single NSManagedObjectContext. What I haven't been able to find out is how Core Data handles atomicity of a save operation for multiple stores.

Let's say I have two stores:

NSPersistentStoreCoordinator *coordinator = [[NSPersistentStoreCoordinator alloc] init];
[coordinator addPersistentStoreWithType:type configuration:@"A" URL:aURL options:nil error:NULL];
[coordinator addPersistentStoreWithType:type configuration:@"B" URL:bURL options:nil error:NULL];

NSManagedObjectContext *context = [[NSManageObjectContext alloc] init];
[context setPersistentStoreCoordinator:coordinator];

And then it's time to save I do that:

NSError *error = nil;
BOOL result = [context save:&error];

The documentation states that the sequence of events will be:

1. Save store A
2. Save store B

What if store A saves correctly, but store B cannot save for some reason? (e.g. the file on disk was deleted, or permissions made it read-only, that sort of thing). I cannot find any documentation detailing whether or not Core Data will then rollback the changes to store A.

It seems odd to me that the object graph would be left in an inconsistent state (i.e. one store updated, one not), but somewhat tricky and resource intensive to perform fully atomic saving across multiple stores. Would just really like some clarification here, perhaps from someone with more experience of the system!

Answer 1

I finally stumbled upon the answer today in CoreDataErrors.h. There is an error code:

    NSPersistentStoreIncompleteSaveError             = 134040, // one or more of the stores returned an error during save (stores/objects that failed will be in userInfo)

So it seems that Core Data will not attempt to roll back saves from the stores that did succeed. And indeed cannot provide atomicity across multiple stores. Fair enough!

Answer 2

This sounds like something that would not be hard to get an experimental answer to by recreating your conditions - have you had time to recreate the scenario you outline?

I would do this by:

1. creating two sqllite stores and writing a set of data to each of the files.
2. shutdown the stores
3. delete the second sqllite file
4. write out an easy to see operation on the first store (might be best to do an insert into one table and delete from the other). Combine this with another operation on the second store and which should fail because of the missing file 5.Check the state of the first store.

It is my feeling that the changes to store A will not be rolled back - but I will be impressed by any other answer.