0

Когда приложение Core Data находится в раннем развитии, его управляемая объектная модель часто находится в постоянном потоке. Для каждой сборки новые управляемые объекты и свойства добавляются или удаляются из модели.Перенос данных с помощью простого ядра при ранней разработке, когда ожидаемая и приемлемая потеря данных

Когда Управляемые изменения объектной модели, приложение будет врезаться на следующем запуске с ошибкой:

The model used to open the store is incompatible with the one used to create the store

common advice in this situation является удалить приложениеfrom your device/simulator and re-run.

Это прекрасно работает для разработчиков, использующих Xcode, но раздражает для нетехнических заинтересованных сторон, участвующих в процессе выпуска. Было бы предпочтительнее не объяснять команде CEO или QA, что они должны удалить приложение перед установкой этого обновления из TestFlight. Или в полевые ошибки, вызванные этой проблемой.

Как только модели были доработаны, мы реализуем стратегию переноса основных данных real.

В этой фазе dev потери данных приемлемы и ожидаются.

Этот метод будет удален до того, как приложение будет выпущено.

Что является самым легким, легким, съемным, отладочным способом «переноса» изменений в управляемую модель объекта между выпусками? Это, скорее всего, будет эквивалентно «удалить приложение и перезапустить», но без необходимости вручную удалять приложение.

Это должно обрабатывать любые изменения в стек основных данных, включая добавление и удаление управляемых объектов и свойств.

ответ

2

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

Рассмотрите возможность использования (в Objective-C)

// error, sourceStoreURL, theManagedObjectModel are valid 

NSDictionary *storeMetadata=[NSPersistentStoreCoordinator metadataForPersistentStoreOfType: NSSQLiteStoreType 
    URL: sourceStoreURL error: &error]; 
BOOL storeIsCurrent=[theManagedObjectModel isConfiguration: nil 
    compatibleWithStoreMetadata: storeMetadata]; 
if (!storeIsCurrent) 
{ 
    // Alert user 
    // Delete on-disk store via sourceStoreURL 
    // (including -wal and -shm files if journaling enabled) 
} 
+0

При этом обязательно удаляйте файлы журнала в дополнение к постоянному файлу хранилища, т. Е. Файлы '-wal' и' -shm' в том же месте. В противном случае вы можете обнаружить, что старые данные фактически не исчезли. –

+0

Спасибо @TomHarrington. Я отредактирую ответ, чтобы включить этот критический момент. – DDP

1

Вы можете изменить URL магазина при изменении модели.

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