Re: CoreData Migration Problems
Re: CoreData Migration Problems
- Subject: Re: CoreData Migration Problems
- From: Gordon Apple <email@hidden>
- Date: Thu, 10 Feb 2011 20:37:23 -0600
- Thread-topic: CoreData Migration Problems
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" <email@hidden> 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#//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 (email@hidden)
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:
This email sent to email@hidden