So far, manual migration has the same result. "migrateStoreFromURL" returns "NO". I even tried deleting a new entity and one attribute from the mapping model, both of which are not involved in the migration. All the others are straightforward.
To rule out some other problems, I also set up a routine to check if the OLD store (the one we are trying to migrate FROM) is compatible with the OLD data model in the NEW program. It returned "YES". #$%^& thing just won't migrate. I'm sure there's some ridiculously obscure reason for it. CoreData is the most finicky thing I have ever dealt with on Mac or iOS. It's conceptually not that difficult, but very unforgiving, and difficult to debug. (Arrrrrg!) (later addendum) Here is a current summary. Old model has several entities, only one, I'll call mainEntity, which is changed in the migration. In the new model, one new entity is referenced from mainEntity, but not involved in the migration. All migrated attributes of mainEntity are identical to the old ones, and simply copied. One new attribute is added to mainEntity. Three old attributes are dropped and not included in mainEntity. That's it, the whole story. The program runs just fine with the new model and generating the database from scratch, or reading in the new database when relaunched. When attempting migration from the old version, the database is successfully checked for compatibility with our old model (just to make sure we hadn't inadvertently changed it). Lightweight migration didn't work. So we created a mapping model, generated by Xcode, which looks to be correct. We attempted a manual migration using the mapping model, but same result. Everything seems to work fine up until migrateStoreFromURL, which returns "NO". The error handles gives 10 console messages, "The operation couldnĀ¹t be completed", which is the exact number of records in the test database. So something is definitely going awry in the mapping. (even later addendum) OK. I've identified the problem. The one new entity relationship in mainEntity is not optional. Changing it to optional allows lightweight migration to work. However, that has its own issues. I had it non-optional for a reason. It is essential in the new database. In mainEntity, I tried adding "awakeFromInsert" and had it create the new entity. However, the migration process apparently never calls this when populating the migrated database. Maybe there is a way to do this with a mapping model and manual migration -- I don't know yet. At this point, it appears that the only option is to make sure I know when it is migrating, set a flag somewhere, then use a fetch request to get all the mainEntity objects and add the new entity to each mainEntity. That's a PITA, and seems like a patch on what should have been a simple process. Any better ideas? On 2/9/11 3:45 AM, "Felix Franz" <fr...@ergosign.de> wrote: > On Feb 8, 2011, at 9:08 PM, Gordon Apple wrote: > >> I am trying to migrate an existing app CoreData database to a new version. >> Theoretically, this should be what's called a simple migration. I have not >> been able to get it to work. Just to see what it's trying to do, I went >> ahead and let it generate a mapping model, which appears to be correct. But >> somehow, it is apparently not reading the original database. The following >> returns nil. >> >> - (NSPersistentStoreCoordinator*)persistentStoreCoordinator { >> if (persistentStoreCoordinator != nil) >> return persistentStoreCoordinator; >> >> NSURL *storeUrl = [NSURL fileURLWithPath: [[[self class] >> appStorageDirectory] stringByAppendingPathComponent: @"myApp.sqlite"]]; >> >> NSDictionary *options = [NSDictionary dictionaryWithObjectsAndKeys: >> [NSNumber numberWithBool:YES], >> NSMigratePersistentStoresAutomaticallyOption, >> [NSNumber numberWithBool:YES], >> NSInferMappingModelAutomaticallyOption, >> nil]; > > If you have a Mapping-Model you don't need the > NSInferMappingModelAutomaticallyOption > (which tries to build a mapping-model on the fly). But I don't think this is > the problem. > > To get a better understanding where the problem is, I would try to do it > manually. > As described in > <http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/CoreDa > taVersioning/Articles/vmInitiating.html%23//apple_ref/doc/uid/TP40005509-SW3> > "The default Migration Process": > > - find the model of the original store. Typed in Mail.app: > > id metaData = [NSPersistentStoreCoordinator metadataForPersistentStoreOfType: > nil URL: storeURL error: &error]; > id model = [NSManagedObjectModel mergedModelFromBundles: bundles > forStoreMetaData: metaData]; > > should give you the model of the original file. > > - find the mapping model: (newModel is your current model) > > id mappingModel = [NSMappingModel mappingModelFromBundles: bundles > forSourceModel: model destinationModel: newModel]; > > If this all goes well you can try to migrate using NSMigrationManager ... As > described as "Manual Migration" in the > document linked above. Hopefully you get better error messages on the way .... > > > Cheers, > > Felix > >> > -- Gordon Apple Ed4U Little Rock, AR _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com