Обзор

Вспомните, что хранилища связываются с их моделями. Когда модель не соответствует хранилище, миграция требуется. Существует две области, где Вы получаете функциональность по умолчанию и рычаги для настройки поведения по умолчанию:

• Когда обнаружение версии скашиваются и инициализация процесса миграции.

• При выполнении процесса миграции.

Выполнять процесс миграции требует двух Базовых Стеков данных — которые автоматически создаются для Вас — один для исходного хранилища, один для целевого хранилища. Процесс миграции выполняется на 3 этапах, копируя объекты от одного штабеля до другого.

Требования для процесса миграции

Миграция персистентного хранилища выполняется экземпляром NSMigrationManager. Для миграции хранилища менеджер по миграции требует нескольких вещей:

• Модель управляемого объекта для целевого хранилища.

  Это - персистентная модель координатора хранилища.

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

• Как правило, отображающаяся модель, определяющая трансформацию из источника (хранилище) модель к целевой модели.

  Вам не нужна отображающаяся модель, если Вы в состоянии использовать легкую миграцию — посмотрите Легкую Миграцию.

Можно указать пользовательские классы миграционной политики объекта для настройки миграции отдельных объектов. Вы указываете пользовательские классы миграционной политики в отображающейся модели (отметьте текстовое поле «Custom Entity Policy Name» на рисунке 4-1).

Пользовательская миграционная политика объекта

Если Ваша новая модель просто добавляет свойства или объекты к Вашей существующей модели, не может быть никакой потребности записать любой пользовательский код. Если трансформация более сложна, однако, Вы, возможно, должны были бы создать подкласс NSEntityMigrationPolicy выполнять трансформацию; например:

• Если у Вас есть объект Лица, также включающий адресную информацию, которую Вы хотите разделить на отдельный объект Адреса, но Вы хотите гарантировать уникальность каждого Адреса.

• Если у Вас есть атрибут, кодирующий данные в формате строки, который Вы хотите изменить на двоичное представление.

Методы, которые Вы переопределяете в пользовательской миграционной политике, соответствуют различным фазам процесса миграции — они вызываются в описании процесса, данного в Трехэтапной Миграции.

Трехэтапная миграция

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

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

Прежде чем цикл запускается, миграционная политика объекта, ответственная за текущий объект, отправляется a beginEntityMapping:manager:error: сообщение. Можно переопределить этот метод для выполнения любой инициализации, которой требует политика. Процесс тогда продолжается следующим образом:

1. Создайте целевые экземпляры на основе исходных экземпляров.

   В начале этой фазы миграционная политика объекта отправляется a createDestinationInstancesForSourceInstance:entityMapping:manager:error: сообщение; в конце это отправляется a endInstanceCreationForEntityMapping:manager:error: сообщение.

   На этом этапе только атрибуты (не отношения) установлены в целевых объектах.

   Экземпляры исходного объекта выбираются. Для каждого экземпляра создаются надлежащие экземпляры целевого объекта (обычно существует только один) и их заполненные атрибуты (для тривиальных случаев, name = $source.name). Учет ведут экземпляров на объект, отображающийся, так как это может быть полезно на втором этапе.

2. Воссоздайте отношения.

   В начале этой фазы миграционная политика объекта отправляется a createRelationshipsForDestinationInstance:entityMapping:manager:error: сообщение; в конце это отправляется a endRelationshipCreationForEntityMapping:manager:error: сообщение.

   Для каждого отображения объекта (в порядке), для каждого целевого экземпляра, создаваемого в первом шаге воссоздаются любые отношения.

3. Проверьте и сохраните.

   В этой фазе миграционная политика объекта отправляется a performCustomValidationForEntityMapping:manager:error: сообщение.

   Правила проверки в целевой модели применяются для обеспечения целостности данных и непротиворечивости, и затем хранилище сохраняется.

В конце цикла миграционная политика объекта отправляется endEntityMapping:manager:error: сообщение. Можно переопределить этот метод для выполнения любой очистки, которую должна сделать политика.

Обратите внимание на то, что Базовые Данные не могут просто выбрать объекты в исходный штабель и вставить их в целевой штабель, объекты должны быть воссозданы в новом штабеле. Базовые Данные поддерживают “таблицы ассоциации”, говорящие их, какой объект в целевом хранилище является перемещенной версией, которой возражают в исходном хранилище, и наоборот. Кроме того, потому что это не имеет средних значений для сбрасывания контекстов, с которыми это работает, можно накопить много объектов в менеджере по миграции, в то время как развивается миграция. Если это представляет значительную память наверху и следовательно дает начало проблемам производительности, можно настроить процесс, как описано в Многократных Передачах — Контакт С Большими Наборами данных.