Ошибка переноса основных данных: «Не удается найти модель для хранилища источника», но имеется управлениеObjectModel для источника - PullRequest
Новая
       20

Ошибка переноса основных данных: «Не удается найти модель для хранилища источника», но имеется управлениеObjectModel для источника

12 голосов
/ 26 декабря 2010

У меня есть приложение какао, использующее данные ядра, которое теперь находится в 4-й версии его модели управляемых объектов.

Моя модель управляемых объектов содержит абстрактные объекты, но до сих пор мне удалось заставить работать миграцию, создав соответствующие модели отображения и создав мое постоянное хранилище, используя addPersistentStoreWithType: configuration: options: error и с NSMigratePersistentStoresAutomaticsOption, установленным в YES.1003 * 

NSDictionary *optionsDictionary = [NSDictionary dictionaryWithObject:[NSNumber numberWithBool:YES] forKey:NSMigratePersistentStoresAutomaticallyOption];
NSURL *url = [NSURL fileURLWithPath: [applicationSupportFolder stringByAppendingPathComponent: @"MyApp.xml"]];
NSError *error=nil;
[theCoordinator addPersistentStoreWithType:NSXMLStoreType configuration:nil URL:url options:optionsDictionary error:&error]

Это прекрасно работает, когда я выполняю миграцию с модели версии 3 на 4, которая включает добавление атрибутов к нескольким объектам.Теперь, когда я пытаюсь добавить новую версию модели (версия 5), вызов addPersistentStoreWithType возвращает nil, и ошибка остается пустой.Переход с 4 на 5 включает добавление одного атрибута.

Я пытаюсь отладить проблему и проверил все следующее:

  1. Исходная база данных фактически на версии 4, а модель управляемого объекта persistentStoreCoordinator - на версии5.

  2. Модель отображения 4-> 5, а также модели управляемых объектов для версий 4 и 5 представлены в папке ресурсов моего встроенного приложения.

  3. Я пробовал различные способы обновления модели.Странно, но я обнаружил, что обновление с ранней версии 3 -> 5 работает .., но обновление с 4 -> 5 не удается.

  4. Я попытался добавить пользовательскую политику миграции сущностей для миграциисущность, атрибуты которой меняются ... в этом случае я переопределил метод beginEntityMapping: manager: error:.Интересно, что этот метод вызывается, когда миграция работает (т.е. когда я мигрирую с 3 на 4 или с 3 на 5), но он не вызывается в случае неудачи (4 на 5).

Я довольно сильно растерялся относительно того, куда двигаться дальше.Любые идеи, которые помогут отладить эту проблему, будут высоко оценены.

1 Ответ

16 голосов
/ 26 декабря 2010

Я отвечаю на свой вопрос здесь, если это кому-нибудь поможет.

Важнейшая проблема заключается в том, что, когда я достиг версии 4 своей объектной модели, я также добавил в проект дополнительную модель управляемых объектов.Эта дополнительная модель была отделена от моей основной модели и просто используется для создания кэша в другом потоке и содержит данные, которые не связаны с основной моделью.

Глупо я по-прежнему инициализировал свой managedObjectModel, используя 

managedObjectModel = [[NSManagedObjectModel mergedModelFromBundles:nil] retain]

, который в моем случае создал модель, содержащую сущности из моей основной модели, а также из моей другой модели.Эти нежелательные объекты имели свои хэши версий в моей базе данных.Когда данные ядра затем отправляются на поиск модели управляемого объекта, которая соответствует всем этим хэшам, она, естественно, не может найти ее.

В моем случае решение состояло в том, чтобы вручную очистить мои файлы БД перед миграцией (удаляя хэши версий из нежелательных объектов).) .. а затем изменить мой код загрузки managedObjectModel на; 

NSString *path = [[NSBundle mainBundle] pathForResource:@"MyDataModel" ofType:@"momd"];
NSURL *momURL = [NSURL fileURLWithPath:path];
managedObjectModel = [[NSManagedObjectModel alloc] initWithContentsOfURL:momURL];
...