После добавления новой версии модели Core Data в мое приложение я выполнил облегченную миграцию, по-видимому, успешно. Мигрированный файл загружен нормально, но при первой попытке доступа к атрибуту через определенные отношения приложение вылетает сNSRangeException: '*** -[__NSArrayM objectAtIndex:]: index 4294967295 beyond bounds [0 .. 35]', Эти отношения работали хорошо до миграции. Я знаю из других сообщений здесь, что 4294967295 действительно-1, но единственное, что я могу идентифицировать с 36 элементами в моем приложении / данных, - это то, что в модели данных имеется всего 36 объектов (для справки: в выбранной связи содержится 58 элементов в таблице).

Вопрос:

Мой вопрос: на основании полученной мной ошибки и устранения неполадок, которые я сделал ниже, существует ли тип изменения схемы, который может пройти легкую миграцию, но повредить данные на этом пути, что приведет к отмеченному исключению? Я попытаюсь разбить миграцию на более мелкие порции в нескольких версиях, чтобы изолировать или избежать этой проблемы, но было бы неплохо иметь возможность сосредоточиться на конкретных изменениях схемы, которые могут быть ошибочными.

Провал:

Ошибка происходит со следующим кодом в «myobject»:

[[self object2] text];

Отношение object2 является взаимно-однозначным, необязательным в обоих направлениях, и ни прямая, ни обратная связь не изменялись между моделями данных.text Атрибут, вероятно, не имеет значения, потому что, когда возникает ошибка,awakeFromFetch не достигается в object2. Если я назначу[self object2] переменная до вышеприведенного утверждения, назначение успешно и сообщаетdata: <fault>.

База данных:

Глядя на базу данных в sqlite3, я замечаю следующее:

Значения индекса для прямых и обратных связей кажутся правильными в каждой таблице.Таблица object2 имеет два столбца для обратной связи вместо столбца до миграции (ZMYOBJECT как и раньше и дополнительныйZ2_MYOBJECT, который является пустым для всех строк). Никакие другие отношения не были добавлены, чтобы объяснить этот столбец.вZ_PRIMARYKEY таблица, все записи после миграции показывают-1 заZ_MAXтогда как до миграции они показывали ноль для пустых таблиц и максимальное количество строк для заполненных таблиц. Обновление вручнуюZ_MAX чтобы правильные значения не помогли с исключением. ВсеZ_SUPER значения были правильными.

Я настроил модель отображения, чтобы посмотреть, не выглядело ли что-нибудь неправильно с автоматическими отображениями, но все выглядело хорошо.

Общие изменения схемы:

В исходной версии модели данных было четырнадцать объектов, из которых только четыре были заполнены данными (приложение все еще находится в разработке). Семь были субъектами высшего уровня, а семь - дочерними объектами трех субъектов высшего уровня.

В целевой версии модели данных было добавлено 22 объекта, некоторые из которых были верхнего уровня, а также некоторые дочерние объекты, с десятками взаимосвязей, включая некоторые, добавленные к существующим объектам.

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

Обновление (25.02.12): когда я начал работать над новой промежуточной моделью, я вспомнил, что я изменил класс (presentClassName) для ряда сущностей с NSManagedObject на подкласс NSManagedObject, но не генерировал файлы классов , Я не подозревал, что это вызовет проблему, и, действительно, создание всех файлов классов не помогло с исключением. Я просто хотел отметить это как очередную смену моделей.

Выводы:

Это неверное предположение, но если подсчет 36 объектов не является совпадением, кажется, что, когда «myobject» пытается выполнить ошибку в «object2», он не имеет допустимой ссылки на таблицу и пытается загрузить таблицу номер -1. , вызывая исключение. Дело в том, что простое назначение[self object2] успешно, однако, не вяжется с этим выводом.

Есть идеи?