1

私のアプリケーションにはNSOperation、マネージド オブジェクトを取得して操作するサブクラスがあります。また、私のアプリケーションはデータベースから行を定期的に削除するため、次の競合状態が発生する可能性があります。

  • バックグラウンド操作は、(スレッド固有のコンテキストから) オブジェクトの束をフェッチします。これらのオブジェクトを繰り返し処理し、それらのプロパティで何かを行います。
  • メインの管理対象オブジェクト コンテキストで一連の行が削除されます。
  • バックグラウンド操作は、メイン コンテキストから削除されたオブジェクトのプロパティにアクセスします。これにより、'NSObjectInaccessibleException', reason: 'CoreData could not fulfill a fault'

理想的には、NSOperation によってフェッチされたオブジェクトは、メイン コンテキストで削除された場合でも操作できます。これを達成するために私が考えることができる最良の方法は、次のいずれかです。

  • [request setReturnsObjectsAsFaults:NO]Core Data がメイン コンテキストに存在しなくなったオブジェクトの障害を解決しようとしないことを確認するために呼び出します。ここでの問題は、オブジェクトの関係にアクセスする必要があるかもしれないということです。
  • 前もってマネージド オブジェクトを繰り返し処理し、必要なプロパティを別の非マネージド オブジェクトにコピーします。ここでの問題は、コピーを完了する前にメインコンテキストでオブジェクトが削除された場合に備えて、この部分を同期/ロックする必要があることです。

明らかな何かが欠けていますか？私が達成しようとしていることは、あまりにも異常なことではないようです。ご協力いただきありがとうございます。

4

3 に答える 3

0

素晴らしい質問です。部分的な回答しか提供できませんが、これについても知りたいです。残念ながら、あなた自身の解決策は回避策ですが、実際には答えではありません。バックグラウンド操作が非常に長く、メイン スレッドで実行することに頼れない場合はどうすればよいでしょうか?

私が言えることの 1 つは[request setReturnsObjectsAsFaults:NO]、フェッチ要求がデータを行キャッシュにロードし、フェッチされたオブジェクトの 1 つで障害が発生したときにデータベースに戻らないため、呼び出す必要がないということです (NSFetchRequest に関する Apple のドキュメントを参照してください)。 ）。ただし、これは人間関係には役立ちません。

私は次のことを試しました：

  1. 通知が来たらNSManagedObjectContextWillSave、現在のバックグラウンド タスクが終了するのを待ち、次のような新しいタスクが開始されないようにします。

    -(void)contextWillSave:(NSNotification *)notification {
    dispatch_sync(self.backgroundQueue, ^{
        self.suspendBackgroundOperation = YES;
    });
}

  2. NSManagedObjectContextDidSave通知時に suspendBackgroundOperation の設定を解除する

ただし、dispatch_sync 呼び出しによってデッドロックが発生する可能性があるため、これも実際には機能しません (関連する質問を参照してください)。さらに、潜在的に長いバックグラウンド操作が完了するまで、メインスレッドをブロックします。

于 2013-03-26T13:05:51.243 に答える
0

同じキューでフェッチと削除の両方を実行することで、これを軽減しました。

于 2012-10-21T22:57:13.290 に答える
0

各スレッドには独自のコンテキストがあるとおっしゃいました。それは良い。ただし、それらは相互に変更された場合でも同期を維持する必要があります (方法は階層によって異なります)。

すべてが同じ永続ストア コーディネーターに割り当てられているか、または親子関係がありますか?

兄弟は、他の兄弟から NSManagedObjectContextObjectsDidChangeNotification を監視する必要があります。子コンテキストが保存されると、親は自動的に通知を受け取ります。

于 2012-05-22T21:32:39.040 に答える