Core Data custom migration failure: Can't add destination store

Question

I have an issue with a core data migration that is failing in way I don't understand.

I have a migration path from an old version of the data model that looks something like this:

1. v1 - initial model
2. v2 - requires light weight migration
3. v3 - requires light weight migration
4. v4 - requires custom migration
5. v5 - light weight migration

I am putting together an integration test to run the migrations from v1 - current. I wrote a small helper that can query the current store, and given a model, run the proper type of migration. This more or less has worked, but I've run into an error on the custom migration step that I don't conceptually understand.

I am using NSMigrationManager::migrateStoreFromURL which has the following description:

Migrates of the store at the specified source URL to the store at the destination URL, performing all of the mappings in the mapping model. A store must exist at the source URL; if a store does not exist at the destination URL, one will be created (otherwise the migration will append to the existing store.) Invoking this method will perform compatibility checks on the source and destination models (and the mapping model.) If an error occurs during the validation or migration, this method will return NO.

The test case copies in a v1 sqlite store and successfully auto migrates to v3, and then fails at the custom migration with this error:

NSUnderlyingError: Error Domain=NSCocoaErrorDomain Code=134100 "The operation couldn’t be completed. (Cocoa error 134100.)"

UserInfo=0x210d740 {metadata={ NSPersistenceFrameworkVersion = 419; NSStoreModelVersionHashes = { lots of hashes that would be noise in this post...}; NSStoreModelVersionHashesVersion = 3; NSStoreModelVersionIdentifiers = ( "" ); NSStoreType = SQLite; NSStoreUUID = "0D2C0907-5F60-4EED-A61B-E726EEB0DA68"; "_NSAutoVacuumLevel" = 2; }, reason=The model used to open the store is incompatible with the one used to create the store

So, just to recap, I only have the source store, which has been auto migrated up to v3. I don't have a destination store, I was hoping to rely on NSMigrationManager to create the destination store. It doesn't make sense to me that the migration would fail due to a model mismatch with a store that doesn't exist. Any ideas?

Just for extra context, when debuggging, I have verified that I am passing in the proper instances of all parameters to the method. The source and destination models have been loaded, the mapping model used for the custom migration was loaded from the test bundle by querying with the source and destination models (a promising result, as this will fail if you have anything wrong), and the URL's for the sqlite stores look right.

Answer 1

First, make sure you add -com.apple.CoreData.MigrationDebug 1 to the arguments passed on launch in your Xcode scheme. Then be careful not to trust the output!

There are problems with matching some models and mapping models, apparently due to incorrect hash values, that don't affect lightweight migration. I am currently fighting with this myself, but I have been unable to isolate the conditions that trigger this, so if you are able to isolate the problem, please file a detailed bug!

If you have access to the iOS 7 beta, the debug output there may be more helpful. In iOS 6, the debug output hash values always match between the mapping models and the managed object models, so there is apparently a bug in the debug output. With iOS 7, you may be able to isolate which entities have has mismatches if this is your problem, and isolate the characteristics that trigger the issue (which I have so far been unable to do).

Just as a sanity check, you might want to try generating a new, clean, vanilla mapping model between versions 3 and 4, with no edits, to make sure nothing is out of sync between your mapping model and the model actually use to generate the store. You may also try the same approach between two models that currently use lightweight migration, to see if the problem occurs in those cases, as may be expected if this is due to the hash value bug(s).