問題タブ [mapping-model]

現在、データ モデルには約 4 つの異なるバージョンがありますが、最後のバージョンを除くすべてのバージョンは、自動軽量移行を使用した小さな変更にすぎません。この最新のモデルでは、移行中に少し追加の作業を行う必要があるため、カスタム マッピング モデルと移行ポリシー サブクラスを作成し、createDestinations と createRelationships でいくつかのアクションを実行しました。問題は、マッピング モデル/カスタム ポリシーが呼び出されず、Core Data が代わりに軽量の移行を実行しようとしているように見えることです。軽量の移行を維持するために必要なことはありますか?ただし、利用可能な場合はマッピング モデルを使用しますか?

Core Dataアプリケーションがあり、コアデータモデルを移行（アップグレード）しています。新しいバージョンを作成するたびに、バージョンごとにマッピングモデルを作成します。現在、16のバージョンがあり、次のようなマッピングモデルがあります：1to2.xcmappingmodel 2to3.xcmappingmodel3to4.xcmappingmodel...など。16まで

これは正常に機能しますが、1人のユーザーがバージョン10のデータファイルを持っていて、バージョン16のアプリケーションを更新すると問題が発生します。CoreDataが自動的に10から16にアップグレードされると思ったのですが、「Missingマッピングモデル」。マッピングモデルが正しいことを確認するために、各バージョンに1つずつアップグレードして（10から11、11から12など）、機能しました...これが私のコードです。

このコードでモデルのバージョンを指定します。

そして、ここで自動移行オプションを定義します。

誰かがこれをアップグレードする方法を知っていますか？ありがとうございました。

約 11Mb の iPhone/iPad sqlite ストアを移行しようとしています。約 30 の異なるエンティティがあり、すべてが非常に相互に関連しています。

3GSでは、かなり時間がかかります。軽量の移行でも約 4 分かかります。

これは、すべての関係がメモリに保持されているためだと思います。

Apple 移行ガイドを読むと、大規模なデータセットの場合、1 つのアプローチは、異なるマッピング モデルを使用して複数のパスを実行することです。

すべて順調です。ただし、あるマッピング モデルのエンティティが別のマッピング モデルのエンティティに関連している場合、これを行うことはできないようです。実際、マッピング モデルの xcmappingmodel ファイルで、「nil マッピング名を使用して値式を自動生成できません」という行に沿ってコンパイル エラーが生成されます。

どんなヒントでも大歓迎です。

どうもありがとう、

マックス

私は今、最初の NSEntityMigrationPolicy を書いていますが、これは非常に単純です。DB からシングルトンをフェッチしてから、他の3 つのタイプのレコードをチャーンし、それらをシングルトンにリンクして、これらのクラスに追加された新しい関係を作成します。

現在、メソッド内の NSEntityMigrationPolicy の単一のサブクラスでこれを行っていendEntityMapping:manager:error:ます。これにより、3 つのタイプすべてのオブジェクトが一度に更新されます。私が確信していないのは、それらすべてを一度に実行しても安全かどうか、または実際に 3 つの個別のポリシーを実装する必要があるかどうかです...endEntityMappingすべての移行が完了した後にコールバックが呼び出されるようです。マッピング モデル エディタで 3 つのクラスすべての「カスタム ポリシー」フィールドにマッピング名を設定すると、1 回しか呼び出されないように見えます。

endEntityMappingこのように単一の implですべてを実行することが安全かどうかを確認したかっただけですか? 確かにそうだと思いますが、これは私が確認したいことです。

助けてくれてありがとう。

私はcore-dataを使用するココアアプリケーションを持っています。これは現在、管理対象オブジェクトモデルの4番目のバージョンです。

管理対象オブジェクトモデルには抽象エンティティが含まれていますが、これまでのところ、適切なマッピングモデルを作成し、addPersistentStoreWithType：configuration：options：errorを使用し、NSMigratePersistentStoresAutomaticallyOptionをYESに設定して永続ストアを作成することで、移行を機能させることができました。

これは、モデルバージョン3から4に移行する場合に正常に機能します。これは、複数のエンティティに属性を追加することを伴う移行です。新しいモデルバージョン（バージョン5）を追加しようとすると、addPersistentStoreWithTypeを呼び出すとnilが返され、エラーは空のままになります。4から5への移行には、単一の属性の追加が含まれます。

私は問題のデバッグに苦労しており、次のすべてをチェックしました。

1. ソースデータベースは実際にはバージョン4であり、persistentStoreCoordinatorの管理対象オブジェクトモデルはバージョン5です。

2. 4-> 5マッピングモデルとバージョン4および5の管理対象オブジェクトモデルは、ビルドしたアプリケーションのリソースフォルダーにあります。

3. さまざまなモデルのアップグレードパスを試しました。不思議なことに、初期バージョン3-> 5からのアップグレードは機能しますが、4->5からのアップグレードは失敗します。

4. 属性が変更されているエンティティの移行用にカスタムエンティティ移行ポリシーを追加しようとしました...この場合、メソッドbeginEntityMapping：manager：error：をオーバーライドしました。興味深いことに、このメソッドは、移行が機能するとき（つまり、3から4、または3から5に移行するとき）に呼び出されますが、失敗した場合（4から5）には呼び出されません。

私はどこに進むべきかについてかなり途方に暮れています。この問題のデバッグに役立つアイデアをいただければ幸いです。

問題を抱えている一部のベータ テスターから奇妙なクラッシュが発生しています。シンボリック化されたクラッシュ レポートは、クラッシュが init 呼び出しでシングルトンとしてのコントローラーの単純な割り当てで発生していることを示していますが、スタック トレースによると、私が持っているコードinitは実際にはクラッシュの場所ではないようです。関連するコードは次のとおりです。

これは以前にクラッシュしたことはなく、コードは最近変更されていません。発生したスタック トレースは次のとおりです。

この不可解なクラッシュが何であり、それがどこから来ているのかについてのアイデアはありますか?

---

更新 1
コア データと移行に関係しているようです。複製できましたが、根本的な原因はまだ不明です。このバージョンには自動移行がいくつかありますが、一部の NSManagedObjects は読み取ることができますが、他のものは特に NSManagedObjects 関係でこの例外をスローしているようです。とは全く関係ないかもしれませんPlayerController。Core-Data の専門家は何か洞察を持っていますか?

---

UPDATE 2クラッシュを再現する方法 と関連するコード
を見つけた後のクラッシュのコールスタックは次のとおりです。

それを再現するために何をしたかを説明するために、データ構造を少し説明する必要があります。MixとAudioアイテムを持っています。ミックスには多くのオーディオがあり、オーディオは多くのミックスに属しています。これは、オーディオを取得するための MixAudio オブジェクトに対する単純な関係呼び出しです。現在、これは、データベースを新しいバージョンに復元した後にのみ、ここでクラッシュしています。

私のセットアップでのデータベースのバックアップとは、データベースを圧縮してデータを保存し、復元時に解凍することを意味します。このクラッシュは、復元プロセスの後にのみ発生します。さらに複雑なことに、マッピング モデルを備えた 3 つのデータベース バージョンがあります。このプロセスはバージョン管理の前に機能していたため、私のバージョンの何かがこのクラッシュを引き起こしているように感じます。

他のすべてのデータは問題なく、アクセスでき、保存もできます。どういうわけか、この単一のフェッチが問題を引き起こしています。永続ストアまたは管理対象オブジェクト モデルの設定時に、エラーや警告は発生しません。さらに、新しい Mix オブジェクトは正常に作成およびアクセスできますが、(復元前に DB にあった) 古いフェッチのみが失敗します。

エラーが見つからない場合、コンソールに次のように表示されます。

クラッシュ行の前後に atry/catchを配置すると、根本的なクラッシュの原因を調べることができます。

しかし、これは (少なくとも私には) 単純なvalueForKey呼び出しには意味がありません。4294967295 = 2^32-1 これは、インデックス var がおそらく -1 に設定されていたことを意味します。私はここで迷っています。

---

[解決済み] 更新 3バージョン管理に含まれていることについては正しかった:) Zarra の本の
バージョン管理に関するセクションを読み直し、DOHの重要な瞬間がありました。3 つのデータベース バージョンを持つアプリを使用したのはこれが初めてです。私は自分のアプリでマッピング モデルを使用していますが、コア データは 1 つのモデルを使用して 1-2 からマッピングし、次に次のモデルを使用して 2-3 にマッピングできると単純に想定していました。1-3 マッピング モデルを持っていないことに気付いたとき、私は文字通り頭を打ちました。それをテストするために、私はすぐに1つ追加しました.すべてがバターと同じくらい滑らかです. 今、私は戻って彼のサンプルを使用して、この DB のバージョンを増やしていくにつれて、私の人生を楽にする必要があります.Progressive Data Migration

Zarra がここに車で来て、何か… 何でも答えてくれることを願っています。

古いデータ モデル、新しいモデル (同じですが、1 つのエンティティに 2 つのテキスト フィールドが追加されています)、およびマッピング モデル (デフォルトで生成されたモデルのみ) があります。

自動移行を行うと、クラッシュが発生し、無限ループに入ったように見えるスタック トレースが表示されます。62851 個のスタック フレーム、ほとんどが _PF_Handler_Public_GetProperty と NSManagedObject の説明であり、malloc エラーで終了します。これは、メモリ不足の無限ループであると想定しています。私のデバイスで。

何がこのような無限ループにつながるのか、何か分かりますか? これをデバッグする場所がわかりません。

乾杯

ニック

新しいバージョンのコア データ モデルに新しいエンティティを追加すると、古いバージョンのコア データ モデルを使用しているアプリがクラッシュしますか?

このエンティティが既存のエンティティと関係を持っている場合はどうなるでしょうか。

私はデータの多いアプリを持っており、XCode のビジュアル マッピング モデルとクリーンアップ コードの NSEntityMigrationPolicy 実装を使用して、すべての CoreData 移行機能を実装しました。結局のところ、実際のデバイスでの移行は非常に時間がかかり、完了までに最大 5 分かかることもあります。

これが進行しているときにユーザーにフィードバックを提供する必要がありmigrationProgress、NSMigrationManager の属性を KVO したいと考えています。トリックはaddPersistentStoreWithType:configuration:URL:options:error:、移行が必要であると見なされた場合に、NSMigrationManager への参照を取得できないようにすることです。

beginEntityMapping:manager:error:カスタム NSEntityMigrationPolicy にコールバックを実装することで、NSMigrationManager への参照を取得できることがわかりました。そこで観察を開始しました。

唯一の問題は、beginEntityMapping通話に到達するまでに進行状況が最大で約 30% であるように見えることです (また、この 30% は通常、 への通話内で費やされた合計時間の約半分addPersistentStoreWithTypeを表すため、実際には見た目よりもさらに悪いです) ）。

アプリの理由についてユーザーにフィードバックを提供する機会の最初の 3 分の 1 を逃さないようにするために、手順の少し前に NSMigrationManager への参照を取得するために使用できるトリックを知っている人はいますか?起動するのにそんなに時間がかかりますか？

助けてくれてありがとう！

CoreData API を広範囲に使用するアプリがあります。エンティティにいくつかのフィールドを追加する更新バージョンを開発しています。スキーマの変更が原因で、ロード時にアプリがクラッシュします (プライベート ストレージを吹き飛ばして再起動しない限り)。

問題は、顧客が新しいバージョンにアップグレードするときです。アプリを初めてロードするときにデータに対してアップグレード手順を実行してもかまいませんが、CoreData がスキーマの変更を好まないため、データをロードすることさえできません。 .

CoreDataに「大丈夫..スキーマの変更について心配しないでください」と伝える方法はありますか? フィールドを追加しただけで、名前を変更したり削除したりしていないためです。