views:

853

answers:

1

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!

+1  A: 

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.

Grouchal
I have not tried this yet. I am somewhat wary of considering the experimental result to be the documented behaviour, as any change in the behaviour would be fairly catastrophic to what I am planning!I was hoping that someone might be able to point me to a scrap of documentation on the matter that I hadn't been able to turn up in my searches.
Mike Abdullah
Well I can't find any documentation. I would then plan for the worst case scenario and assume the rollback won't work over two data stores and make sure you code can handle this in some way. You could always try doing inserts into dummy tables before starting your big transaction to make sure the state of the stores is OK.
Grouchal