Предполагаемая миграция основных данных - автоматическая облегченная или ручная

Я обновил модель существующего приложения для iPhone несколькими простыми способами (удалить атрибут, добавить атрибут, удалить индекс) и могу использовать автоматическую облегченную миграцию для миграции постоянного хранилища.

Из-за типичного размера набора данных время обработки немаловажно и требует обратной связи от пользователя.

NSMigrationManager предоставляет простое, но полезное migrationProgress значение, которое отправляет уведомления KVO по мере выполнения миграции. Это составляет основу обратной связи, однако попытка использовать предполагаемую модель ([NSMappingModel inferredMappingModelForSourceModel:destinationModel:error:]) приводит к совершенно разным временным характеристикам для одного и того же набора данных.

Результаты профиля на исходном iPhone (2 ГБ), размер кеш-памяти: 1,785 МБ на диске.

Автоматическая предполагаемая упрощенная миграция

PROFILE: CacheManager -migrateStore
PROFILE:   0.6130 (+0.6130) models loaded
PROFILE:   1.1759 (+0.5629) delegate -CacheManagerWillMigrate:
PROFILE:   1.2516 (+0.0757) persistent store coordinator loaded
PROFILE:   5.1436 (+3.8920) automatic lightweight migration completed
PROFILE:   5.5435 (+0.3999) delegate -CacheManagerDidFinishMigration:withError:

Предполагаемый перенос вручную

PROFILE: CacheManager -migrateStore
PROFILE:   0.6660 (+0.6660) models loaded
PROFILE:   1.1471 (+0.4811) inferred mapping model generated
PROFILE:   1.4046 (+0.2574) delegate -CacheManagerWillMigrate:
PROFILE:   1.5058 (+0.1013) persistent store coordinator loaded
PROFILE:   22.6952 (+21.1894) manual migration completed
PROFILE:   23.1478 (+0.4525) delegate -CacheManagerDidFinishMigration:withError:

Таким образом, с предполагаемой моделью перенос вручную занимает в 5 раз больше времени, чем автоматический!

ОБНОВЛЕНИЕ: загрузка модели

Документация Core Data для _6 >> noreferrer ">" Варианты переноса " говорит:

NSInferMappingModelAutomaticallyOption

... координатор попытается вывести модель отображения, если ее не удастся найти.

И именно поэтому построенная, скомпилированная и объединенная модель сопоставления XCode должна быть удалена (или просто не настроена на таргетинг), чтобы произошла предполагаемая и облегченная миграция.

Это большая несогласованность, и параметр облегченный, который NSPersistentStoreCoordinator -addPersistentStoreWithType:configuration:URL:options:error: не дает абсолютно никакой индикации прогресса во время обработки.

Может ли кто-нибудь предоставить поддерживаемый способ получения значений migrationProgress во время автоматической миграции, ИЛИ способ настроить предполагаемую модель сопоставления на такую ​​же скорость при ручной обработке, как и при автоматической?

ОБНОВЛЕНИЕ: отчет об ошибке

Поговорили с инженерами WWDC, и они попросили отчет об ошибке с запросом migrationProgress для автоматической обработки облегченной миграции.

Я обновлю еще раз, если API обновится, чтобы добавить отчеты о ходе выполнения ..


iphone objective-c migration core-data mapping-model
person ohhorob    schedule 29.03.2010    source источник
comment
Какие-нибудь обновления через полдесятилетия?   -  person Rafael Bugajewski    schedule 24.08.2015

Ответы (2)


arrow_upward
3
arrow_downward

В настоящее время Core Data использует частный класс NSSQLiteInPlaceMigrationManager для выполнения облегченной миграции. Это подкласс NSMigrationManager, но обрабатывает все самостоятельно в migrateStoreFromURL:type:options:withMappingModel:toDestinationURL:destinationType:destinationOptions:error:. Судя по всему, этот класс на самом деле выполняет изменения непосредственно в хранилище SQLite, а не втягивает все в память, как того требует ручная миграция.

Это объясняет, почему вы видите, что упрощенная миграция выполняется намного быстрее.

К сожалению, даже если вы используете эти знания о частных API, которые используются за кулисами, это не принесет вам большой пользы от получения индикации прогресса. Значение прогресса в настоящее время никогда не изменяется для NSSQLiteInPlaceMigrationManager, оно всегда равно нулю. Значение currentEntityMapping также, похоже, осталось нулевым.

Пока Apple не предоставит API, похоже, нам не повезло. У вас есть номер радара, чтобы я мог открыть дубликат?

person wbyoung    schedule 15.03.2012

arrow_upward
2
arrow_downward

Что произойдет, если вы сами определите модель сопоставления вместо использования предполагаемой модели? Похоже, создание предполагаемой модели снижает производительность, которую решит прямое определение модели сопоставления и ее включение в ваш проект.

Обновить

Я уже пробовал эту стратегию, и использование модели сопоставления, созданной в XCode, дает примерно такое же время обработки, что и модель, предполагаемая во время выполнения. Единственное реальное отличие состоит в том, что время загрузки модели из пакета немного быстрее, чем время, предполагаемое во время выполнения. Кроме того, как только модель сопоставления включена в приложение, автоматическая миграция перестает быть легкой, я предполагаю, что она использует связанную модель. Удаление модели сопоставления с цели возвращает время обработки к ~ 4 секундам для автоматического облегчения

Это определенно противоречит интуиции. Достаточно ли прост ваш проект, чтобы опубликовать его в качестве примера этой неэффективности, или у вас, возможно, есть тестовый проект, который изолирует эту проблему? В любой ситуации было бы очень полезно взглянуть на это, чтобы мы могли: а) надеюсь, разгадать загадку; или B) сообщить об этом как о довольно крупной ошибке в Apple, поскольку, безусловно, должно иметь место обратное.

Насколько велик набор данных, с которым вы работаете?

person Marcus S. Zarra    schedule 29.03.2010
comment
Я уже пробовал эту стратегию, и использование модели сопоставления, созданной в XCode, дает примерно такое же время обработки, что и модель, предполагаемая во время выполнения. Единственное реальное отличие состоит в том, что время загрузки модели из пакета немного быстрее, чем время, предполагаемое во время выполнения. Кроме того, как только модель сопоставления включена в приложение, автоматическая миграция перестает быть легкой, я предполагаю, что она использует связанную модель. Удаление модели сопоставления с цели возвращает время обработки к ~ 4 секундам для автоматического облегчения - person ohhorob; 29.03.2010
comment
Я обновил вопрос со ссылкой на документацию о том, почему модель сопоставления, созданная XCode, должна быть удалена. Согласно деталям вопроса, постоянное хранилище занимает менее 2 МБ на диске. Я профилирую миграцию на исходном iPhone, чтобы оценить худшую производительность, которую можно ожидать во время обработки. - person ohhorob; 30.03.2010