Apple の docによると、次のようになっています。
変更をコンテキストに保存すると、その変更は「1 つ上のストア」にのみコミットされます。子コンテキストを保存すると、変更はその親にプッシュされます。ルート コンテキストが保存されるまで、変更は永続ストアに保存されません。(ルート管理対象オブジェクト コンテキストは、親コンテキストが nil のコンテキストです。) さらに、親は、保存する前に子から変更をプルしません。最終的に変更をコミットする場合は、子コンテキストを保存する必要があります。
私のデータモデルは、大まかに次のNSManagedObject
階層で構成されています。
Category <---->> Feed <---->> Post
私のアプリケーションである RSS リーダーは、次のものを使用します。
Concurrency タイプ
NSManagedObjectContext
の「ルート」 。NSPrivateQueueConcurrencyType
この MOC を使用して、変更を に永続化しNSPersistentStoreCoordinator
ます。Concurrency タイプ
NSManagedObjectContext
の「メイン」 。NSMainQueueConcurrencyType
この MOC を使用して GUI にフィードします。Concurrency タイプ
NSManagedObjectContext
の「ローカル」 。NSPrivateQueueConcurrencyType
新しい Posts オブジェクトのバッチを作成するときに、この MOC を使用します。
だから、私の質問は次のとおりです。
- を保存する
localMOC
と、自動的に に反映されますmainMOC
か? または、 から観察NSManagedObjectContextDidSaveNotification
し、localMOC
手動で両方の MOC を とマージする必要がありmergeChangesFromContextDidSaveNotification
ますか? - 昨日まで、バッチ インポートは に送信される外部
DBOperation <NSOperation>
コンテキストで行われていましたNSOperationQueue
が、同期はどのように行われるのでしょうか? eachの親として使用するにはmainMOC
、 をパラメーターとして渡す必要がありますか?DBOperation
localMOC
- バッチルーチンを元に戻しました
MainViewController
が、それが良いアイデアだったかどうかはわかりません。以前のように固執する必要がありますかNSOperationQueue
、それとも現在の[localMOC performBlock:^{ ... }];
構造はまともなバックグラウンド処理を提供しますか?
よろしくお願いします。