CoreDataエンティティ「A」はCoreData、カスケード削除ルールを使用して、エントリ「B」のコレクションに対して1対多の関係にあります。
環境ではiCloud、デバイス1は「B」エントリの1つの詳細ビューを表示しますが、デバイス2は「A」エントリを削除します。
NSPersistentStoreDidImportUbiquitousContentChangesNotificationデバイス1で通知を受信すると、そのApp Delegateが呼び出して内部通知をブロードキャストします。このmergeChangesFromContextDidSaveNotification通知は、ビューコントローラーによってキャプチャされ、エントリ「B」の詳細を示します（コードは必要なperformBlock場所を使用します）。
ただし、詳細ビューコントローラが内部通知を受信すると、エントリ「A」は実際に無効になりますが、エントリ「B」は引き続き有効なCoreDataオブジェクトとして存在します。カスケードルールはまだ動作を完了していないようです。したがって、デバイス1のView Controllerは削除を認識しません。これにより、予期しない結果が生じる可能性があります。
mergeChangesFromContextDidSaveNotificationベースデータがマージされたが、カスケードルールがまだ完了していない場合、時期尚早に戻るように見えます。
管理対象オブジェクトコンテキストのを一時的にゼロに設定し、キャッシュされたオブジェクトが使用されないように通知が到着したときにエントリ「B」を更新しようとしましたstalenessIntervalが、ストアから有効なエントリ「B」を取得します。
この時点でエントリ「A」をチェックするnullことはオプションではありません。これは、状況がここで説明したものよりもいくらか複雑であり、場合によってはnullエントリ「A」が有効になる可能性があるためです。
変更をマージした後、内部通知をViewControllerに送信する前に遅延を導入しようとしました。2秒の遅延は役に立たないことがわかりましたが、10秒の遅延は機能します。
しかし、私はこの遅れに頼りたくありません。これは多くのデータがないテスト環境であり、本番環境で何が起こるかわかりません。実験的な遅延に依存することは正しいことではないようです。
正しいことはありますか？それとも私は最初に何か間違ったことをしていますか？