Проблемы с памятью при переносе больших хранилищ данных CoreData на iPhone

Question

Под моим приложением находится потенциально очень большое хранилище данных CoreData (оно может быть больше 30 МБ).Я начал замечать проблемы с памятью при использовании автоматической миграции (addPersistentStoreWithType:configuration:URL:options:error:), поэтому я начал изучать методы переноса небольших частей хранилища, чтобы избежать всего накопления объекта CoreData, которое происходит, когда вы переносите все сразу.

Это обсуждается в официальной документации в разделе «Несколько проходов», однако похоже, что предлагаемый ими подход состоит в том, чтобы разделить миграцию по типу сущности, то есть создать несколько моделей сопоставления, каждая из которыхперенести подмножество типов сущностей из полной модели данных.

Единственная проблема - что, если один тип сущностей составляет большинство вашего хранилища данных?Если следовать подходу, рекомендованному Apple, весь тип сущности все еще будет выполнен за одну миграцию, и проблемы с памятью, вероятно, будут сохраняться.

Существуют ли какие-либо методы, доступные для фактической миграции поднабора сущностейопределенного типа, чтобы гарантировать, что вам не хватит памяти при попытке перенести их все?

Заранее спасибо за любую помощь.

РЕДАКТИРОВАТЬ: После выполнения дополнительных копаний я обнаружил,что рекомендованное Apple разделение БД на типы сущностей на самом деле работает только для несвязанных сущностей (как обсуждено здесь ), поэтому вероятность решения проблем БД в реальном мире даже ниже, чем я думалкогда я изначально писал этот пост.

Я начинаю думать, что миграции CoreData, которые на самом деле выполняются с помощью NSMigrationManager, теперь вообще не масштабируются, и у вас в принципе не может быть БД, размер которой превышает примерно 20-30 МБ, если вы хотите иметь возможность перенести его на устройства iOS текущего поколения.Единственный жизнеспособный подход, по-видимому, состоит в том, чтобы полностью замкнуть все NSMigrationManager / NSMappingModel и написать миграцию полностью в коде.Похоже на огромную оплошность со стороны Apple, если это действительно так.

Answer 1

Я смог обойти это в краткосрочной перспективе, используя «облегченную» миграцию, как описано в http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/CoreDataVersioning/Articles/vmLightweight.html#//apple_ref/doc/uid/TP40008426-DontLinkElementID_1.

Хитрость заключается в том, чтобы получить подкласс NSMigrationManager, который специально предназначен для типов хранилищ SQLite,вы вручную вызываете миграцию, как показано в последнем примере кода на этой странице.

Это исправление не общего назначения, поскольку оно работает только в том случае, если изменение схемы в вашем хранилище данных достаточно простое, чтобыВозможна легкая миграция.Все еще жду ответа от Apple относительно рекомендуемого решения, когда вы работаете с нетривиальным отображением.