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

Вопрос:

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

Провал:

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

[[self object2] text];

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

База данных:

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

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

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

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

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

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

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

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

Выводы:

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

Есть идеи?