0

NSOperationsを使用してマルチスレッドアプリでCoreDataを操作する際に問題が発生しています。次のように、MagicalRecord（2.0.3）を介してネストされたManagedObjectContextsを使用しています。

Root Context (saves to disk)
|
Main Thread Context (for populating the UI)
|
Sub-Context(s) (used to add/edit/remove data)

すべてのデータ処理を処理する単一のNSOperationQueueがあります。

ほとんどの場合、問題はありません。データを非同期でダウンロードし、NSOperationにフィードして、サブコンテキストの1つに書き込むことができます。操作の最後に保存すると、変更がメインコンテキストにプッシュされ、UIが更新されます。素晴らしい！

問題は、サブコンテキストがエンティティを削除して保存（メインコンテキストにプッシュ）した場合でも、兄弟のサブコンテキストはエンティティが存在すると見なすということです。したがって、兄弟がエンティティに障害を発生させ、その親（メインコンテキスト）からプルしようとすると、クラッシュします。

2つの質問があります：

  • MOC通知を使用して、メインMOCにプッシュされた変更を他の子にマージする必要がありますか？私はこれと別のクラッシュを取得していました...
  • 複数のサブコンテキストも必要ですか？MOCは単一のスレッドに関連付けられているはずであり（MagicalRecordはこれを自動化するのに役立ちます）、データを保存するための単一のNSOperationQueueがあるので、サブコンテキストを1つだけにするべきではありませんか？保存が異なるコンテキストで実行されることがあることを確認しました。

アドバイスをいただければ幸いです。ありがとう。

4

1 に答える 1

1

複数のサブコンテキストを持つことができ、またそうすべきです。ただし、コンテキストの従来の「スレッド分離モード」が、もう必要なモデルであるかどうかはわかりません。これは、コンテキストが特定のスレッドに属する必要があると言うときに実行していることです。MagicalRecord 2.0xは現在、プライベートキューコンテキストを使用しているため、動作が少し異なります。兄弟コンテキストの同期を維持する必要があるという規則はありません。あなたはそれを自分でしなければならないでしょう。非常に簡単な解決策は、保存しているコンテキストで「保存しました」通知をリッスンし、リセットするか、他のスレッドで新しいコンテキストを作成することです。これは、通知、またはMagicalRecordが提供するコンプリーションブラックを使用して行うことができます。

お役に立てれば

于 2012-07-30T18:43:06.523 に答える