2011-02-02 1 views
1

私のアプリは、CoreDataデータストアの下に潜在的に非常に大きなCoreDataデータストアを持っています(これは簡単に30MB以上になる可能性があります)。私は自動移行(addPersistentStoreWithType:configuration:URL:options:error:)を使用する際にメモリの問題に気付き始めました。そこで、すべてを一度に移行する際に発生するCoreDataオブジェクトの蓄積を避けるため、ストアの小さな部分を移行する方法を検討しました。メモリ上で大規模なCoreDataデータストアをiPhoneで移行する場合

これは「複数パス」セクションのofficial documentationで説明されていますが、エンティティタイプごとにマイグレーションを分割する、すなわちエンティティのサブセットを移行する複数のマッピングモデルを作成することが推奨されているようです完全なデータモデルからの型。

唯一の問題は、1つのエンティティタイプがデータストアの大半を占めている場合です。アップルが推奨するアプローチによれば、エンティティタイプ全体は1回の移行でまだ実行されており、メモリの問題はおそらく続きます。

特定のタイプのエンティティのサブセットを実際に移行して、それらをすべて移行しようとしたときにメモリが不足しないようにする技術はありますか?

ご協力いただきありがとうございます。

EDIT:アップルが推奨するエンティティタイプへの分割は、実際には関連性のないエンティティ(discussed hereなど)にしか適用されないことが判明しました。私がこの本を初めて書いたときに思ったよりも実世界のDBです。

実際にNSMigrationManagerを介して実行されるCoreDataの移行は今ではスケールされていないと思っています。あなたができるようにするには、基本的に約20-30MBを超えるDBを使用できません。現世代のiOSデバイス上に移行します。実行可能な唯一のアプローチは、すべてのNSMigrationManager/NSMappingModelの内容を完全に短絡し、完全なカスタムをコードに書き込むことです。実際にそうであれば、アップルの面倒を見ているようだ。

答えて

1

http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/CoreDataVersioning/Articles/vmLightweight.html#//apple_ref/doc/uid/TP40008426-DontLinkElementID_1に記載されているように、「軽量」の移行を利用することで、短期間にこの問題を回避することができました。

トリックは、そのページの最後のコードサンプルに示すように、手動でマイグレーションを呼び出すときにSQLiteストアタイプ用のNSMigrationManagerサブクラスをプルすることです。

これは汎用の修正ではありませんが、これは、データストア内のスキーマの変更が簡単で軽量の移行が可能な場合にのみ機能するためです。 Appleから、些細でないマッピングを扱っているときに推奨される解決策が何であるかを聞いています。

+0

Appleから聞いて、その解決策は... ummm ...自分でやってください。したがって、基本的には、あなたのアプリケーションに大きなDBがある場合は、あなたのマイグレーションが推論/軽量モデルによって実行できることを確認するためにあなたの力ですべてを行います。きれい。 – glenc

関連する問題