В чем разница между управлением версиями модели и интеграцией данных?

Question

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

Answer 1

Управление версиями используется так же, как управление версиями в приложениях, для указания различных изменяющихся вариаций одного и того же базового кода, за исключением базовых данных, эволюция кода - это модель данных, т.е. сущности, свойства сущностей и отношения, определенные в файле .xcdatamodel.

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

Работает так:

Вы выпускаете версию 1.0 вашего приложения, которая также является моделью данных с версией 1.0. Конечный пользователь затем использует ваше приложение и сохраняет свои данные в постоянном хранилище, отформатированном / структурированном с использованием вашей модели данных 1.0.

Затем вы выпускаете версию 2.0 своего приложения и вносите изменения в модель данных в процессе, например, Вы изменяете имя свойства, добавляете свойство или добавляете сущность. Вы бы также вернули модель данных на что-то вроде 2.0 (фактические имена версий являются произвольными.) Затем вы предоставляете автоматическую или ручную миграцию, чтобы данные конечного пользователя в файле постоянного хранилища 1.0 можно было переформатировать в модель данных 2.0. формат.

Answer 2

Каждое изменение, которое вы вносите в модель Core Data, приводит к новой версии.КАЖДОЕ изменение.

Базовые данные не имеют понятия, что одна модель новее другой, хотя они просто знают, что они разные.Core Data не будет использовать хранилище (базу данных на диске), созданное версией модели, отличной от той, что у вас есть.

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

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

Когда следует создавать миграцию?По сути, каждый раз, когда вы отправляете новую версию в магазин, вам нужно найти путь от любой предыдущей модели, которая была в магазине (и, следовательно, может быть на чьем-то телефоне), до последней версии модели данных.Как уже отмечалось, если изменения просты, вы можете использовать автоматическую версию, но всегда тестируйте (держите каждый выпуск магазина приложений доступным для сборки, чтобы вы могли протестировать загрузку более старой версии и переход на новую).

Между прочим, приемлемый план состоит в том, чтобы просто удалить существующую базу данных, если модель вообще изменилась, при условии, что вы можете поместить что-либо, что пользователь сделал назад, в базу данных каким-либо образом (или если пользователь никогда ничего не помещал ввсе, как в кеширующей базе).