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

Question

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

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

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

Результаты профиля на оригинальном iPhone (2G), размер кэша: 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 раз больше времени, чем автоматическая!

---

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

Документация по базовым данным для NSPersistentStoreCoordinator «Параметры миграции» говорит:

NSInferMappingModelAutomaticallyOption

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

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

---

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

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

---

ОБНОВЛЕНИЕ: Сообщение об ошибке

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

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

Answer 1

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

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

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

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

Answer 2

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

обновление

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

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

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