これは非常に具体的な質問であり、私はちょうど今それに悩まされているので、他の人の時間と苦痛を救うために、ここに私の問題の詳細と解決策を示します.
たとえば、メイン コンテキストを保存すると、NSFetchedResultsController デリゲート コールバックがトリガーされます。保存が実際に完了したという事実に依存できますか。また、現在保存されているデータが含まれていると仮定して、それらのコールバック内で新しいフェッチ リクエストを安全に実行できますか。 ?
答えはノーだ。
これは非常に具体的な質問であり、私はちょうど今それに悩まされているので、他の人の時間と苦痛を救うために、ここに私の問題の詳細と解決策を示します.
たとえば、メイン コンテキストを保存すると、NSFetchedResultsController デリゲート コールバックがトリガーされます。保存が実際に完了したという事実に依存できますか。また、現在保存されているデータが含まれていると仮定して、それらのコールバック内で新しいフェッチ リクエストを安全に実行できますか。 ?
答えはノーだ。
アプリにアクティブな NSFetchedResultsController (NSFRC) があり、デリゲート セットがあり、関連するオブジェクトへの変更を監視している場合は、すべての Core Data 開発者が知っておくべき文書化されていない小さな警告があります。メイン コンテキストで保存を実行し、NSFRC がメイン コンテキストで動作している場合、メイン コンテキストを呼び出すとsave:
、実際には NSFRC が最初に更新され、実際に MOC コンテンツをディスク。willChangeContent:..
didChangeContent:..
これが問題になる理由は、NSDictionaryResultType
NSFRC コールバック内の resultType を使用して新しいフェッチ リクエストを実行しようとすると、フェッチ リクエストに現在の変更が含まれないためです。現在の変更とは、NSFRC コールバックが最初に呼び出された変更を意味します。
これらの変更が表示されない理由は、resultType を設定するとプロパティNSDictionaryResultType
がオフになるためincludesPendingChanges
です。そのため、フェッチ リクエストはディスクから直接変更を取得するだけで、コンテキストからローカルの変更をマージすることはありません。
ディクショナリの結果タイプを使用した任意のフェッチ リクエストが保存されていない結果をコンテキストからマージしない理由はある程度理解できます。これは、MOC がグラフ内のオブジェクトと関係をモデル化している間、ディクショナリが任意の構造を持つ可能性があるためです。私にとって興味深く、驚くべきことは、保存が実際に行われる前に NSFRC デリゲートが更新コールバックを取得したことでした。
ここにいくつかの ASCII アートがあります:
1. メイン MOC を保存 --> | 2. NSFRC コールバック --> | 3. 実際の保存はここで行われます | | | | | | | | | | | | | | ▼ | | | NSDictionaryResultType | | | フェッチ要求はしません | | | | からの変更を参照してください。 | | この現在の保存ですが | | | 通常のフェッチ リクエスト | | | これらの変更が表示されます |
PS: Core Data は、限られたパフォーマンスのデバイスで実行されるオブジェクト グラフ管理フレームワークです。時には最適化しなければなりません。