問題タブ [nspersistentstore]

Xcode を使用して開発用の新しいマシンをセットアップしました。既存のコア データ プロジェクト (古いマシンでも完全に動作します) を開いてビルドし、実行すると、「nil モデルで NSPersistentStoreCoordinator を作成できません」というメッセージが表示されます。 " エラー。

このエラーに関連するスタックオーバーフローに関する無数の質問を読みました。そのおかげで、iOS がデータベース オブジェクト モデルを処理する方法をよりよく理解できたと感じています。私が知る限り、明らかな問題はありません。

管理対象オブジェクト モデルに標準の初期化方法を使用しています。つまり...

...古いマシンでは素敵な NSManagedObjectModel を返していますが、新しいマシンでは nil です。

コンパイルされているバンドルには project.momd フォルダーが含まれており、このフォルダーには project.mom ファイルが含まれています。これは私の古いマシンでコンパイルされた出力とまったく同じですが、実行されるものと実行されないものがあります。非常にイライラします！

私が考えることができる唯一のことは、新しいマシンで正しく設定していない Xcode 内の構成オプションがあるということですが、助けやアドバイスをいただければ幸いです。

* アップデート *

新しいマシンのバンドルには、Project.momd 内に project.mom が含まれています。私の古いマシンでは、Project.mom は Project.momd の中にあり、モデル名は大文字と小文字が区別されると推測しているので、xcode がママを小文字でコンパイルしている理由を解読する必要があります...

バンドル内で手動で project.mom の名前を Project.mom に変更すると、プロジェクトが再コンパイルされるまで一時的ではありますが、実際に問題が解決されます。

NSManagedObjectContext永続ストアと親コンテキストの両方が設定され、保存が呼び出されるとどうなりますか？データを永続ストアと親コンテキストの両方に1つずつプッシュしますか？それとも同時にそれをしますか？それとも、コアデータは単に不平を言う例外を投げますか？

APIは、特定のコンテキストに対して1つが2つの「親」を設定することを直接停止しません。

永続ストレージにリレーショナル データベースを使用するカスタムNSIncrementalStoreサブクラスを実装しています。私がまだ苦労していることの 1 つは、楽観的ロックのサポートです。

（以下の私の質問にこの長い説明を飛ばしてください）

Core Data の SQLite 増分ストアが生成する SQL ログを調べることで、この問題にどのようにアプローチするかを分析し、次の結論に達しました。

• データベース内の各エンティティ テーブルには、このエンティティ (行) の特定のインスタンスが変更された回数を 1 (最初の挿入) から始まるZ_OPT列があります。

• 管理オブジェクトが変更されるたびに、対応するデータベース行のZ_OPT値が増加します。

• ストアは、 NSIncrementalStoreNodeインスタンスのキャッシュ ( Core Data ドキュメントでは行キャッシュと呼ばれます) を維持します。それぞれのインスタンスは、管理対象オブジェクトの行に対する前のSELECTまたはUPDATE SQL クエリによって返されたZ_OPT値と等しいバージョンプロパティを持ちます。

• 管理対象オブジェクトが NSManagedObjectContext から返されると(たとえば、NSFetchRequestを実行することによって)、MOC はこのバージョン番号を含むこのオブジェクトのスナップショットを作成します。

• オブジェクトが変更または削除されると、Core Data は、キャッシュされた行とオブジェクトのスナップショットのバージョンを比較して、コンテキスト外で変更または削除されていないことを確認します。これはすべて、オブジェクトが属するコンテキストで-save:が呼び出されたときに発生します。バージョンが異なる場合、マージ競合が検出され、設定されたマージ ポリシーに基づいて処理されます。

MOC が保存されると、変更/削除されたオブジェクトごとに-newValuesForObjectWithID:withContext:error:メソッドが呼び出され、バージョン番号とともにNSIncrementalStoreNodeが返されます。次に、このバージョンがスナップショットのバージョンと比較され、それらが異なる場合、保存は適切なマージ競合で失敗します (少なくともデフォルトのマージ ポリシーでは)。

-newValuesForObjectWithID:withContext:error:オブジェクトが同じストア インスタンスを使用して他のコンテキストで同時に変更された場合、行キャッシュを最初にチェックするため、この単純な使用例は私のストアで適切に機能します。この場合、競合を検出するのに十分な、より高いバージョン番号を持つ更新された行がキャッシュに含まれます。

しかし、同じデータベース ファイルを使用する他のアプリケーションまたは他のストア インスタンスによって、基になるデータベースがストア外で変更されたことをどのように検出できますか? これはめったにない特殊なケースであることはわかっていますが、Core Data はそれを適切に処理しており、私も同じようにしたいと考えています。

Core Data のストアは、次のような SQL クエリを使用して、オブジェクトの行を更新/削除します。

X - (キャッシュから) ストアに最後に認識されたバージョン番号
Y - 新しいバージョン番号

このようなクエリが失敗した場合 (影響を受ける行がない場合)、行はストアのキャッシュで更新され、そのバージョンが以前にキャッシュされたものと比較されます。

私の質問は次のとおりです。カスタムNSIncrementalStoreは、一部の更新/削除/ロックされたオブジェクトで楽観的ロックの失敗が発生したことを Core Data にどのように通知できますか? NSSaveChangesRequestを処理するときに-executeRequest:withContext:error:メソッドが渡されたことを認識できるのはストアだけです。

基礎となるデータベースがストアの下で変更されない場合、Core Data が-newValuesForObjectWithID:withContext:error:を変更/削除/ロックされたオブジェクトごとに呼び出してから、ストアで変更の保存要求を実行するため、競合が検出されます。NSIncrementalStoreが保存要求の処理を開始した後に楽観的ロックの失敗が発生したことを Core Data に通知する方法を見つけることができませんでした。それを行うための文書化されていない方法はありますか？その場合、Core Data はいくつかの例外をスローするように見えますが、これは魔法のように失敗した保存要求に変換され、NSError がすべての競合を一覧表示します。-executeRequest:withContext:error:から nil を返すことによってのみ、部分的に模倣することができます。自分でエラーメッセージを作成します。このシナリオでも、標準の Core Data 競合処理メカニズムを使用する方法が必要だと思います。

私はいくつかの記事を読みましたが、NSIncrementalStoreコンセプト全体についてまだ混乱しています。この投稿では、次のことがわかります。

基本的に、 のカスタム サブクラスを作成できるようになりましたNSPersistentStore。これによりNSFetchRequest、ローカルの SQLite データベースにアクセスする代わりに、結果を返す任意の処理 (ネットワーク リクエストの作成など) を実行できる、定義したメソッドが実行されます。

この時点まで、NSIncrementalStore はリモート データにアクセスしてローカルに保存/キャッシュするための完璧なソリューションであると考えていました。ここで、これはリモート データにアクセスするためだけのソリューションであると推測します。

私が正しければ、いくつかの回避策に関するアドバイスに感謝します。私が間違っている場合、魔法はどこにあり、どのように実装するのですか? NSIncrementalStore のすべての投稿/記事/チュートリアルは、サーバーからデータをプルするのがいかに簡単かを示していますが、オフラインで表示するために物事をキャッシュすることについては、1 つの手がかりも与えていません。

答えとして、ユーザーがアプリをオフラインで使用できるように、アプリがインターネットからデータをダウンロードして表示し、ローカルに保存するという一般的なシナリオを考えてみましょう。

また、私は NSIncrementalStore などを使用することを約束していません。私はちょうど最善の解決策を探しています.このクラスは、この分野の最高の専門家によって説明されました.

私は、iCloud ストアをアプリケーション サンドボックスのローカル ストレージに移行する作業を行ってきました。コードは次のようになります (わかりやすくするために、エラー処理コードは削除されています)。

この時点で、iCloud ストアをアプリケーション サンドボックスの新しい場所に正常に移行しましたが、iCloud にはまだデータがあり、古い sqlite ファイルが配置されています... 次の行は sqlite ファイルを削除します

したがって、これらすべてを実行した後、私のファイル システムと永続ストアは、私が知る限り良好に見えます。1 つ欠けているのは、iCloud に保存されたデータが iCloud から削除されないことです (ただし、アプリからはアクセスされなくなります)。プログラムで iCloud データを削除するには、他に何が必要ですか? Apple iCloud のドキュメントには、トランザクション ログの削除が記載されていますが、ドキュメント フォルダにクリーンアップが必要な他のファイルはありません。どんな助けでも大歓迎です！

アップデート：

iCloud ストアは、最初は次のオプションを使用してセットアップされました。