Faulting и Uniquing
Сбой является Данными Ядра механизма, использует для сокращения использования памяти приложения. Связанная функция, названная uniquing, гарантирует, чтобы в данном контексте управляемого объекта у Вас никогда не было больше чем одного управляемого объекта представлять данную запись.
Сбой ограничивает размер графа объектов
Сбой сокращает объем памяти, который использует Ваше приложение. Отказ является объектом местозаполнителя, представляющим управляемый объект, полностью еще не понятый, или объект коллекции, представляющий отношение:
Отказ управляемого объекта является экземпляром надлежащего класса, но еще не инициализируются его персистентные переменные.
Отказ отношения является подклассом класса набора, представляющего отношение.
Сбой позволяет Базовым Данным помещать границы на граф объектов. Поскольку отказ не понят, отказ управляемого объекта использует меньше памяти, и управляемые объекты, связанные с отказом, не требуются, чтобы быть представленными в памяти вообще.
Для иллюстрирования рассмотрите заявление, позволяющее пользователю выбирать и редактировать подробные данные о единственном сотруднике. У сотрудника есть отношение менеджеру и к отделу, и эти объекты поочередно имеют другие отношения. Если Вы получаете просто единственный объект Сотрудника от персистентного хранилища, его менеджера, отдела, и отношения отчетов первоначально представлены отказами. Рисунок 1 показывает отношение отдела сотрудника, представленное отказом.
Несмотря на то, что отказ является экземпляром класса Отдела, он еще не был понят — ни одна из его персистентных переменных экземпляра еще не была установлена. Это означает, что мало того, что объект отдела использует самой меньше памяти, но нет никакой потребности заполнить ее отношение сотрудников. Если это было требование, чтобы граф объектов был завершен, то отредактировать единственный атрибут единственного сотрудника, в конечном счете было бы необходимо создать объекты представлять целую корпоративную структуру.
Обработка отказа прозрачна — Вы не должны выполнять выборку для понимания отказа. Если на некотором этапе к персистентному свойству объекта отказа получают доступ, то Базовые Данные автоматически получают данные для объекта и инициализируют объект (см. Ссылку класса NSManagedObject для списка методов, не заставляющих отказы стрелять). Этот процесс обычно упоминается как увольнение отказа. Если Вы отправляете объекту Отдела сообщение для получения, скажем, его имени, то отказ стреляет — и в этом Ядре ситуации Данные выполняют выборку для Вас для получения атрибутов всего объекта.
Увольнение отказов
Базовые Данные автоматически запускают отказы, когда необходимый (когда к персистентному свойству отказа получают доступ). Однако увольнение отказов индивидуально может быть неэффективным, и существуют лучшие стратегии получения данных от персистентного хранилища (см. Пакетный Сбой и Упреждающую выборку с Хранилищем SQLite). Для больше о том, как эффективно иметь дело с отказами и отношениями, посмотрите Выбирающие Управляемые объекты.
Когда отказ запущен, Базовые Данные не возвращаются к хранилищу, если данные доступны в своем кэше. С удачным обращением в кэш, преобразовывая отказ в реализованный управляемый объект очень быстро — это - в основном то же как нормальное инстанцирование управляемого объекта. Если данные не доступны в кэше, Базовые Данные автоматически выполняют выборку для объекта отказа; это приводит к циклу обработки к персистентному хранилищу для выборки данных, и снова данные кэшируются в памяти.
Заключение этой точки - то, что, является ли объект отказом, не то же как, были ли его данные получены от хранилища. Является ли объект отказом, просто означает, имеет ли данный управляемый объект все свои заполненные атрибуты и готов использовать. Если необходимо определить, является ли объект отказом, можно отправить его isFault сообщение, не запуская отказ. Если isFault возвраты NO, тогда данные должны быть в памяти. Однако, если isFault возвраты YES, это не подразумевает, что данные не находятся в памяти. Данные могут быть в памяти, или это не может, в зависимости от многих факторов, влияющих на кэширование.
Превращение объектов в отказы
Превращение реализованного объекта в отказ может быть полезным в сокращении графа объектов (см. Сокращающую Память Наверху), а также гарантирующий значения свойств являются текущими (см., что Данные Обеспечения Актуальны). Превращение управляемого объекта в отказ выпускает ненужную память, устанавливает ее значения свойств в памяти в nil, и сильные ссылки повреждений к связанным объектам.
Можно превратить реализованный объект в отказ с refreshObject:mergeChanges: метод. Если Вы передаете NO как mergeChanges параметр, необходимо быть уверены, что нет никаких изменений в отношениях того объекта. Если будет, и Вы тогда сохраняете контекст, то Вы представите проблемы ссылочной целостности персистентному хранилищу.
Когда объект превращается в отказ, он отправляется a didTurnIntoFault сообщение. Можно реализовать пользовательское didTurnIntoFault метод для выполнения различных функций «обслуживания» (см., например, Гарантируя Данные, Актуален).
Отказы и уведомления KVO
Когда Базовые Данные превращают объект в отказ, уведомления изменения наблюдения значения ключа (KVO) (см., что Значение ключа Наблюдает Руководство по программированию), отправляются за свойствами объекта. Если Вы наблюдаете свойства объекта, превращенного в отказ, и отказ впоследствии понят, Вы получаете уведомления изменения для свойств, значения которых фактически не изменились.
Несмотря на то, что значения не изменяются семантически с Вашей точки зрения, литеральные байты в памяти изменяются, поскольку осуществлен объект. Механизм наблюдения значения ключа требует, чтобы Базовые Данные выпустили уведомление каждый раз, когда значения изменяются, как рассмотрено с точки зрения сравнения указателя. KVO нужны эти уведомления для отслеживания изменений через ключевые пути и зависимые объекты.
Uniquing гарантирует отдельный управляемый объект на запись на контекст
Базовые Данные гарантируют, что — в данном контексте управляемого объекта — запись в персистентном хранилище связана только с одним управляемым объектом. Метод известен как uniquing. Без uniquing Вы могли бы закончить с контекстом, поддерживающим больше чем один объект представлять данную запись.
Например, считайте ситуацию проиллюстрированной на рисунке 2; два сотрудника были выбраны в контекст отдельного управляемого объекта. У каждого есть отношение к отделу, но отдел в настоящее время представляется отказом.
Казалось бы, что у каждого сотрудника есть отдельный отдел, и если бы Вы попросили у каждого сотрудника их отдела поочередно — превращение отказов в регулярные объекты, то — у Вас было бы два отдельных объекта Отдела в памяти. Однако, если оба сотрудника принадлежат тому же отделу (например, «Представляя на рынке»), то Базовые Данные гарантируют, что (в данном контексте управляемого объекта) когда-либо создается только один объект, представляющий Маркетинговый отдел. Если бы оба сотрудника принадлежат тому же отделу, их отношения отдела оба поэтому сослались бы на тот же отказ, как проиллюстрировано на рисунке 3.
Если бы Базовые Данные не использовали uniquing, то, если Вы выбрали всех сотрудников и попросили у каждого поочередно их отдела — таким образом, увольнения соответствующих отказов — новый объект Отдела создавался бы каждый раз. Это привело бы ко многим объектам, каждый представляющий тот же отдел, который мог содержать различные и противоречивые данные. Когда контекст был сохранен, будет невозможно определить, который является корректными данными для передавания хранилища.
Более широко все управляемые объекты в данном контексте, относящиеся к Маркетинговому объекту Отдела, относятся к тому же экземпляру — у них есть единственное представление данных Маркетинга — даже если это - отказ.