Можете ли вы отредактировать один и тот же NSManagedObject в 2 разных ManagedObjectContexts и объединить их изменения?

Question

Я синхронизируюсь с базой данных MySQL.

Первоначально я собирался пройтись по всем моим новым / измененным объектам и установить все внешние ключи для этого объекта, а затем выполнить следующий объект и так далее ... Но это много запросов на выборку.

Так что вместо этого я хотел просмотреть все мои новые / измененные объекты и установить внешние ключи по одному. Итак, первый проход по моим объектам устанавливает fk1, мои следующие наборы fk2, и так далее ...

Круто, выборочные запросы резко сокращены. Теперь мне любопытно, смогу ли я использовать эти сеттеры. Они не зависят друг от друга, но они изменяют один и тот же объект, даже если они устанавливают только одно отношение, а это другое отношение. Говоря в терминах git, эти изменения могут быть «объединены» вместе без какого-либо конфликта, но возможно ли передать изменения в одном дочернем managedObjectContext (childContext: save) до parentManagedObjectContext (parent: executeBlock ^ {parent: save}) и извлечь это в другом, другом дочернем элементе managedObjectContext (???)? Или политика слияния примет только одну версию объекта childContext и фактически оставит другие fks без изменений.

Я знаю, что это существует: NSManagedObjectContext / refreshObject: mergeChanges:

Но это на объекте на уровне объекта. Это вызовет кучу уловок? Или это обновит весь мой контекст сразу / в пакетном режиме?

Следуя предложению Apple отсюда: https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/CoreData/Articles/cdImporting.html Я создал / обновил свои значения до того, как начал устанавливать какие-либо отношения, поэтому все объекты уже существуют, прежде чем я попытаюсь указать на них какие-либо отношения.

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

Answer 1

Я не уверен, что вы пытаетесь сделать и почему (вы можете написать меньше строк в своем вопросе и быть более понятным), но вот несколько рекомендаций по работе с основными данными:

-NSManagedObjectContext не является потокобезопасным.Следовательно, вам необходимо ограничить доступ к этому контексту управляемого объекта, чтобы это происходило внутри 1 потока.В противном случае вы можете получить много ошибок, которые вы не можете понять.- NSManagedObjectContexts помимо выполнения других вещей, служит «снимками» вашего постоянного хранилища.Это означает, что когда вы изменяете объект, вы сохраняете его в постоянном хранилище, вы публикуете NSManagedObjectContextDidSaveNotification и затем вызываете mergeChangesFromContextDidSaveNotification: в другом месте вашей программы, чтобы загрузить последние данные из постоянного хранилища.Будьте осторожны с безопасностью потоков.

NSManagedObjectContext / refreshObject: mergeChanges: согласно Apple, речь идет не просто об обновлении управляемого объекта.Если вы передадите YES в качестве второго аргумента, он запишет все ожидающие изменения из этого контекста управляемого объекта в постоянное хранилище и загрузит любые другие изменения других свойств этого объекта из постоянного хранилища, таким образом «синхронизируя» ваш объект спостоянный магазин.Если вы передадите NO в качестве второго аргумента, объект потеряет все ожидающие изменения, и он превращается в ошибку.Это означает, что при попытке доступа к нему контекст управляемого объекта перезагрузит объект в том виде, в котором он был последний раз сохранен в базе данных.Это НЕ перезагрузит весь контекст управляемого объекта.Он будет работать только на объекте.

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

Я надеюсь, что помог.