Атомарный жизненный цикл хранилища
Эта статья описывает жизненный цикл атомарного хранилища. Необходимо считать эту статью для изучения, какие методы вызываются на хранилище, когда, и что хранилище, как ожидают, сделает в результате. Это поможет Вам понять, как реализовать пользовательское хранилище.
Регистрация
Для использования пользовательского типа хранилища в приложении необходимо зарегистрировать тип хранилища в NSPersistentStoreCoordinator использование класса registerStoreClass:forStoreType:. Для получения дополнительной информации посмотрите Регистрацию Пользовательского Типа Хранилища.
Инициализация и загружающиеся данные
Вы создаете экземпляр хранилища данного типа с помощью NSPersistentStoreCoordinator метод addPersistentStoreWithType:configuration:URL:options:error:. Необходимо реализовать надлежащие методы, чтобы должным образом инициализировать хранилище и загрузить его содержание.
Инициализация хранилища
Координатор выделяет новое хранилище и инициализирует его использующий с initWithPersistentStoreCoordinator:configurationName:URL:options:. Этот метод вызывается и для новых хранилищ и для существующих хранилищ; Ваша реализация initWithPersistentStoreCoordinator:configurationName:URL:options: должен поэтому проверить, существует ли файл в данном URL — если он не делает, необходимо создать его.
Необходимо также инициализировать метаданные для хранилища. После initWithPersistentStoreCoordinator:configurationName:URL:options:, координатор вызывает metadata на новом хранилище; в этой точке метаданные должны быть корректными.
После того, как хранилище инициализируется, координатор дает хранилищу команду загружать свои данные путем отправки ему a load: сообщение.
Загрузка файла
load: метод должен получить данные хранилища от URL, указанного для хранилища в initWithPersistentStoreCoordinator:configurationName:URL:options:. load: метод должен проанализировать содержание хранилища, чтобы извлечь персистентные данные и создать объект справочных данных — такой как словарь — для каждого элемента.
Для каждого объекта, который будет представлен, Ваше хранилище должно сделать следующее:
Создайте управляемый объект ID со справочными данными и типом объекта для узла, с помощью
objectIDForEntity:referenceObject:.Идентификатор объекта для узла кэша является также идентификатором объекта для управляемого объекта, представляющего узел кэша.
Создайте узел кэша (экземпляр
NSAtomicStoreCacheNode), использованиеinitWithObjectID:.Хранилище должно обеспечить непостоянный объект кэша свойства для каждого узла.
(Необязательно) Нажатие соответствующие сохраненные данные в узел.
Этот шаг может быть опущен при реализации ленивой загрузки или другого поведения.
Реализация по умолчанию
NSAtomicStoreCacheNodeобеспечивает значение ключа, кодирующее совместимый доступ для хранения свойства, таким образом, для общего падежа Вы не должны создавать пользовательский подклассNSAtomicStoreCacheNode.
Как только все узлы были созданы, Вы регистрируете их в использовании хранилища addCacheNodes:.
В этой точке кэш теперь зарегистрировал узлы, и платформа готова. Базовые Данные обработают все запросы для выборок и создадут управляемые объекты из базовой информации об узле кэша.
Этот процесс описан более подробно, с примерами, в Инициализации и Загружающихся Данных.
Файлы нулевой длины
Любой подкласс NSAtomicStore должен быть в состоянии обработать быть инициализированным с URL, указывающим на файл нулевой длины. Это служит индикатором, что новое хранилище должно быть создано в указанном расположении и позволяет Вам надежно создавать файлы резервирования в известных расположениях, которые могут тогда быть переданы Базовым Данным для построения хранилищ.
Можно принять решение создать файлы резервирования нулевой длины во время initWithPersistentStoreCoordinator:configurationName:URL:options: или load: метод. Если Вы делаете так, необходимо удалить файл резервирования, если хранилище удалено от координатора, прежде чем это будет сохранено.
Обработка и сохранение изменений
Когда контекст управляемого объекта отправляется a save: сообщение, любое связанное хранилище должно (в этом порядке), обрабатывают все вставленные, обновленные и удаленные объекты, присваивающиеся ему (хранилище), и затем передающие любые изменения во внешнем репозитории.
Новые объекты
Для каждого недавно-вставленного-объекта в контексте хранилище получает a
newReferenceObjectForManagedObject:сообщение. Ваше хранилище должно обеспечить уникальное — и неизменный — оценивают за этот экземпляр и тип объекта для хранилища (см. Новые Ссылочные Объекты).После того, как справочные данные возвращаются, хранилище запрашивает, чтобы новый узел кэша был создан для каждого из этих объектов использование
newCacheNodeForManagedObject:.NSAtomicStoreобеспечивает реализацию по умолчанию, которая должна быть достаточной в большинстве случаев, Однако если Вы хотите настроить создание узлов кэша или использовать пользовательские узлы кэша, можно переопределитьnewCacheNodeForManagedObject:. В Вашей реализации необходимо создать узел кэша с управляемым объектом ID от включенного управляемого объекта, и значения, которые будут сохранены, должны быть продвинуты от управляемого объекта в узел кэша. Вы тогда регистрируете новые узлы в хранилище, с помощьюaddCacheNodes:Обновленные объекты
Для всех объектов, изменяющихся в контексте, хранилище получает a
updateCacheNode:fromManagedObject:сообщение. Параметрами за метод является объект узла кэша и пара управляемого объекта (которые совместно используют тот же идентификатор объекта.) Хранилище должно продвинуть сохраненные значения от управляемого объекта в узел кэша.Удаленные объекты
Ваше хранилище получает a
willRemoveCacheNodes:обратный вызов; если необходимый можно переопределить этот метод для повреждения каких-либо циклов сильной ссылки, чтобы гарантировать, что в отношении удаленных объектов предъявляют претензии.Сохранение изменений
Наконец, хранилище получает a
save:сообщение для передачи изменений во внешнем репозитории.Ваше хранилище должно записать данные (узлы кэша) и метаданные к URL, указанному для хранилища в любом формате, который это использует.
Новые ссылочные объекты
Ваша реализация newReferenceObjectForManagedObject: должен возвратить стабильное (неизменное) значение для любого данного объекта. Если Вы не делаете этого, то Сохраняете Как, и операции миграции не будут работать правильно.
Это означает, что можно только использовать произвольные числа, UUIDs или другие случайные значения при сохранении значения вместе с остальной частью данных для данного объекта. Если Вы не можете сохранить первоначально присвоенный ссылочный объект, то newReferenceObjectForManagedObject: должен получить ссылочный объект из значений управляемого объекта. Поскольку это ограничение существует для Сохранения Как и операции миграции хранилища, Вы могли также использовать приставной стол или структуру данных в памяти, чтобы гарантировать, что недавно перемещенное хранилище загружает свои атомарные узлы кэша хранилища тем же objectIDs, который текущий контекст управляемого объекта использует для перемещенных управляемых объектов.
Удаление и освобождение
Если хранилище должно быть удалено от координатора, оно получает сообщение willRemoveFromPersistentStoreCoordinator:. В пользовательском атомарном классе хранилища можно переопределить этот метод для реализации очистки или другого поведения. Если Вы делаете, Ваша реализация willRemoveFromPersistentStoreCoordinator: должен вызвать реализацию super.
Обратите внимание на то, что параметр координатора может быть nil если:
Во время загрузки была ошибка: метод и хранилище не могут быть добавлены к координатору
Координатор находится в процессе того, чтобы быть освобожденным.
В этих случаях, willRemoveFromPersistentStoreCoordinator: вызывается, чтобы позволить Вам выполнять любую необходимую очистку ресурса (такую как удаление файлов резервирования — посмотрите Файлы Нулевой Длины).