Два контекста управляемого объекта (один вложен в другой через setParent :), оба настроены с использованием NSMainQueueConcurrency: это разумно? - PullRequest
Новая
       15

Два контекста управляемого объекта (один вложен в другой через setParent :), оба настроены с использованием NSMainQueueConcurrency: это разумно?

1 голос
/ 17 ноября 2011

Я использую два контекста управляемого объекта в своем приложении для iOS. Первый контекст является родительским для второго, использующего новую модель вложенных управляемых контекстов, представленную в iOS 5. Оба этих контекста были созданы с помощью NSMainQueueConcurrencyType.

То, чего я пытаюсь добиться, - это хороший способ обработки временных дополнений и изменений в моих данных, которые могут сохраняться или не сохраняться и имеют логическое различие, когда объект основного контроллера владеет первым контекстом (родительским) и подчиненным. Контроллер владеет 2-ым контекстом (дочерний). Таким образом, изменения всплывают, и главный контроллер может решить, сохранять или нет свой контекст. Тот факт, что мои контексты являются вложенными, требует, чтобы они были настроены , а не с использованием шаблона ограничения (NSConfinementConcurrencyType).

Мой вопрос: этот шаблон я пытаюсь реализовать некорректно? Я только что прочитал из нескольких постов, что использование нескольких контекстов в основном потоке, вероятно, не лучшая идея в большинстве случаев. Я также изо всех сил пытаюсь определить, где я должен использовать performBlockAndWait: в моих контекстах. Должен ли я использовать его каждый раз, когда сообщение отправляется в контекст, даже если я уверен, что в данный момент я выполняю его в главном потоке? Включает ли это места, где я создаю новый NSManagedObject, например: 

    [theManagedObjectContext performBlockAndWait:^
    {
        id *myObj = [NSEntityDescription insertNewObjectForEntityForName:@"MyEntity" inManagedObjectContext:theManagedObjectContext];
        // more stuff done here
    }];

А как насчет мест, где я делаю изменения в моих NSManagedObjects? Нужно ли мне обернуть их в performBlockAndWait:? Как насчет мест, где я использую NSFetchedResultsController и отправляю ему сообщение performFetch?

Мне лучше использовать один контекст и выяснить, как работает менеджер отмены?

Документация по этим новым функциям Core Data очень скудна из того, что я видел ...

1 Ответ

1 голос
/ 17 ноября 2011

Насколько я понимаю, вы всегда должны использовать блочные методы -performBlock: и -performBlockAndWait: при отправке сообщений в NSManagedObjectContext, который не был инициализирован с использованием шаблона ограничения. Очевидно, какой метод вы используете, будет зависеть от ваших потребностей.

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

...