Поддержка параллелизма контекстов управляемого объекта

NSManagedObjectContext теперь предоставляет структурированную поддержку для параллельных операций. Когда Вы создаете использование контекста управляемого объекта initWithConcurrencyType:, у Вас есть три опции для его потока (очередь) ассоциация

• Ограничение (NSConfinementConcurrencyType).

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

  Вы не можете использовать этот тип параллелизма в сочетании с новой вложенной функцией контекстов (см. Вложенные Контексты Управляемого объекта).

• Частная очередь (NSPrivateQueueConcurrencyType).

  Контекст создает и управляет частной очередью.

• Основная очередь (NSMainQueueConcurrencyType).

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

Можно использовать контексты с помощью образца ограничения, как Вы имеете до OS X v10.7 и iOS 5. Вы отправляете сообщения контекстов непосредственно; Вам решать, чтобы гарантировать, чтобы Вы отправили сообщения от правильной очереди.

Вы используете контексты с помощью основанных на очереди типов параллелизма в сочетании с двумя новыми методами: performBlock: и performBlockAndWait:. Вы группируете «стандартные» сообщения для отправки к контексту (включая инициализацию, такую как установка персистентного координатора хранилища и т.д.) в блоке для передачи одному из этих методов. Одно исключение: если Ваш код выполняется на основном потоке, можно вызвать методы на основные контексты стиля очереди непосредственно вместо того, чтобы использовать блок, базируемый API.

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

Важно ценить, что блоки выполняются как отличное собрание произведений. Как только Ваши концы блока, кто-либо еще может ставить в очередь другой блок, изменения отмены, сбросьте контекст и т.д. Таким образом блоки могут быть довольно большими, и обычно заканчиваться путем вызова save:.

__block NSError *error;

__block BOOL savedOK = NO;

[myMOC performBlockAndWait:^{

    // Do lots of things with the context.

    savedOK = [myMOC save:&error];

}];

Можно также выполнить другие операции, такие как:

NSFetchRequest *fr = [NSFetchRequest fetchRequestWithEntityName:@"Entity"];

__block NSUInteger rCount = 0;

[context performBlockAndWait:^() {

    NSError *error;

    rCount = [context countForFetchRequest:fr error:&error];

    if (rCount == NSNotFound) {

        // Handle the error.

    }

}];

NSLog(@"Retrieved %d items", (int)rCount);

Вложенные контексты управляемого объекта

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

• Выполнение фоновых работ на втором потоке или очереди.

• Управляя отбрасываемыми редактированиями, такой как в окне инспектора или представлении.

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

При сохранении изменений в контексте изменения только фиксируются, “каждый запасает”. При сохранении дочернего контекста изменения продвинуты к его родителю. Эти изменения не сохраняются к персистентному хранилищу, пока не сохраняется корневой контекст. (Корневой контекст управляемого объекта является тем, родитель которого nil.), Кроме того, родитель не вытягивает изменения от дочерних элементов, прежде чем он сохранит. Если Вы хотите в конечном счете фиксировать изменения, необходимо сохранить дочерние контексты.

Вложенные контексты делают его более важным чем когда-либо, что Вы принимаете “передачу маркер” подход доступа к контексту (путем передачи контекста от одного контроллера представления до следующего) вместо того, чтобы получить его непосредственно от делегата приложения.

Инкрементное хранилище

Базовые Данные обеспечивают два новых класса, NSIncrementalStore и NSIncrementalStoreNode, то, что можно использовать для реализации поддержки неатомарных персистентных хранилищ. Хранилище не должно быть реляционной базой данных — например, Вы могли использовать веб-сервис в качестве бэкэнда.

Базовый сбой Информационной поддержки и другие аспекты управления графом объектов и другие аспекты управления графом объектов в домене NSManagedObjectContext. Интерфейс от персистентного координатора хранилища к пользовательскому инкрементному хранилищу через NSPersistentStoreRequest объекты. Это не обеспечивает генерацию SQL, интерпретацию предиката, или любые другие удобства общедоступной платформы продали хранилища.

Базовые Данные отправляют указания, чтобы получить от хранилища и сохранить данные к хранилищу с помощью персистентных запросов хранилища. NSPersistentStoreRequest новый класс, теперь служащий суперклассом NSFetchRequest и другой новый класс, NSSaveChangesRequest. NSPersistentStoreRequest обеспечивает атрибуты, указывающие, какие хранилища затронуты запросом, и является ли это сохранением или запросом выборки. Сохранение изменяется, запрос указывает, какие управляемые объекты вставлены, удалены и обновлены, и те, которые были отмечены для оптимистической блокировки.

Если Ваше приложение не должно, при реализации хранилища Вы не должны поддерживать все формы запроса выборки. Действительно, NSFetchRequest так мощно, Вы призваны рассмотреть запуск, только поддерживая предконсервированные запросы в Вашем инкрементном хранилище, определенном для потребностей Вашего приложения.

Управляемые объекты

Управляемые объекты поддерживают две существенно новых функции: упорядоченные отношения и внешнее хранение для значений атрибута.

• Упорядоченные отношения представлены экземплярами NSOrderedSet вместо NSSet. NSOrderedSet не наследовался от NSSet. Вы используете mutableOrderedSetValueForKey: вместо mutableSetValueForKey: получать непостоянный прокси для отношения.

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

• Небольшие значения данных как миниатюры изображения могут быть эффективно сохранены в базе данных, но большие фотографии или другие носители лучше всего обрабатываются непосредственно файловой системой. Можно теперь указать, что значение атрибута управляемого объекта может быть сохранено, как видит внешняя запись — setAllowsExternalBinaryDataStorage:. Когда включено, Базовые Данные эвристическим образом выбирают на стоимостный базис, если они должны сохранить данные непосредственно в базе данных или сохранить URI к отдельному файлу, которым они управляют для Вас. Вы не можете запросить на основе содержания свойства двоичных данных при использовании этой опции.

Запросы выборки

Можно указать имя объекта, который Вы хотите выбрать как строка путем инициализации использования запроса выборки initWithEntityName:. Это обычно проще, чем использование setEntity: и необходимость получить надлежащее NSEntityDescription объект от модели. Это действительно означает, однако, что запрос entity остается “в неопределенности”, пока Вы фактически не выполняете запрос, в которой точке описание объекта получено через персистентного координатора хранилища контекста и установлено как значение. Если Вы вызываете entity перед использованием запроса Базовые Данные выдают исключение.

Можно использовать setShouldRefreshRefetchedObjects: для конфигурирования выборки для получения новых значений для управляемых объектов, это получает. Ранее, Вы имели к также reset контекст или явно обновляет отдельное использование управляемых объектов refreshObject:mergeChanges:. Иначе даже если соответствующая запись изменилась в персистентном хранилище, при выборке того же объекта много раз он содержал бы те же значения свойств.

Если Вы используете хранилище SQLite, и Вы конфигурируете запрос выборки к возвращаемым значениям как словари (NSDictionaryResultType), можно сгруппировать использование результатов setPropertiesToGroupBy:. Это позволяет Вам выполнить совокупные операции — например, можно сгруппировать сотрудников отделом. При указании свойств для группировки, можно также указать “предикат наличия” (setHavingPredicate:) отфильтровать возвращаемые группы.

Управляемые документы

Базовые Данные обеспечивают интеграцию с архитектурой документа iOS и так с «облачным» хранилищем. UIManagedDocument конкретный подкласс UIDocument это использует Базовые Данные персистентное хранилище для хранения данных документа. При инициализации управляемого документа Вы указываете URL для расположения документа. Объект документа тогда создает Базовый Стек данных для использования для доступа к персистентному хранилищу документа с помощью модели управляемого объекта от основного пакета приложения.

UIManagedDocument выполняет всю основную установку, в которой Вы нуждаетесь для Базовых Данных. Можно, тем не менее, предоставить параметры конфигурации для создания координатора и для модели. Можно выполнить дополнительную настройку путем создания подкласса UIManagedDocument.