6

このエラーが発生する理由を理解しています。別のスレッドのマネージド オブジェクト コンテキストで削除された CoreData オブジェクトにアクセスしようとしたため、「障害」オブジェクトに設定され、保持された参照は有効なオブジェクトを指しなくなりました。 CoreData オブジェクト。

私は NSFetchedResultsController を使用しています。

すべてのコードが正しく実装されていることを確認しました。2 つのマネージド オブジェクト コンテキストがあり、1 つは BG スレッド用で、もう 1 つはメイン スレッド用です。

メインスレッドが NSManagedObjectContextDidSaveNotification 配下の通知にサブスクライブされていることを確認しました。

この通知が発生したときに、メイン スレッドのマネージド オブジェクト コンテキストで mergeChangesFromContextDidSaveNotification: を実行することを確認しました。

これらのオブジェクトをどこにも保持していませんが、NSFetchRequest のバッチ サイズを設定しています (これは潜在的に問題ですか?)

それでも、「CoreData は障害を実行できませんでした」というエラーが時々表示されます。

私の特定のアプリケーションでは、これは通常、一種の「データバインド」プロセス中に発生するため、障害オブジェクトを安全に破棄して先に進むことができました。@try-catch ブロックでデータ バインドするループの内部をラップし、CoreData エラーが発生した行をスキップすることで、これを実行したいと考えています。

これを CoreData で安全に実行できますか? または、障害が発生した後、管理オブジェクト コンテキストを完全にダンプする必要がありますか。

CoreData オブジェクトが fault であるかどうかを確認する方法について、この質問を確認しました。これは、 @try-catch ブロックが他の問題を引き起こさないと安全に想定できない場合に実装するものかもしれません。

4

1 に答える 1

15

try-catch を使用する代わりに、「existingOjectWithId」を使用して、返されたオブジェクトの nil をチェックできます。

- (NSManagedObject*)existingObjectWithID:(NSManagedObjectID*)objectID error:(NSError**)error 

上記は、指定された ID のオブジェクトがコンテキストに既に登録されている場合はそのオブジェクトを返します。または、オブジェクトをコンテキストにフォールトさせます。オブジェクトがフェッチできない場合、存在しない場合、または障害が発生しない場合は、 nil を返します。-objectWithID とは異なり、エラーを返すことはありません。

于 2013-08-14T07:03:55.310 に答える