1.x コード ベースから 2.x コード ベースに移行する際に、かなり大きなコア データ ベースのデータベース スキーマ (最大 20 エンティティ、140 以上のプロパティ) が大幅に変更されています。
私は軽量の移行を実行することに非常に精通していますが、関連するオブジェクトをエンティティ自体の変換可能な属性として保存するために使用されるエンティティがいくつかあるため、この特定の移行には少し当惑していますが、今はそれらを実際のエンティティに移行したいと考えています.
これは、軽量の移行ではなく重い移行を使用する必要がある場合の完璧な例のように思えますが、私はそれについてもあまり満足していません. 私は大規模な移行に慣れていません。この配列を持つエンティティの 1 つ -> モデル化された関係の変換が発生し、データベース内の行の約 90% を占めます。これらのデータベースのサイズは 200 MB を超える傾向があります。お客様のかなりの部分が iPad 1s を使用しています。これは、Apple のドキュメントと Marcus Zarra の (優れた) Core Data ブックで、大量の移行の速度とメモリ使用量に関する警告が繰り返されることと相まって、私は非常に用心深くなり、この状況を処理する別の方法を探しています。
WWDC 2010 の「Mastering Core Data」セッション 118 (スライドはこちら、ログインが必要です。最後のスライドの 9 番目から 'Migration Post-Processing' というタイトルが付いています) では、これを回避する方法について言及しています。移行を実行してから、ストア メタデータを使用して、または実行したいカスタム後処理が完了していません。私はこれが進むべき道かもしれないと思っていますが、（より良い言葉がないため）少しハッキーに感じます。また、実際には非推奨になっている属性をぶら下げたままにしておくことも心配です。元。エンティティ foo の barArray 属性をエンティティ foo とエンティティ bar の間の関係に移動し、barArray を削除しても、barArray は書き込みおよび読み取りが可能な属性として存在します。これを解決する潜在的な方法は、名前を「非推奨」に変更して、これらの属性が非推奨であることを知らせることです。
これは私が意図した以上のブレイン ダンプになってしまったので、明確にするために、私の質問は次のとおり
です。(ビジネスに不可欠なアプリ、大規模な移行の経験がない、サイズが 200 MB を超えるデータベース、数万行、iOS 5 以降を実行する iPad 1 を使用している顧客
) 118 私の最善の策は？
3) もしそうなら、コードベースを汚染しないように、これらの「非推奨」属性をすぐに/最終的に削除するにはどうすればよいですか?