Что такое миграция базы данных (Database Migration)?

А, ну вот, опять эти ваши миграции баз данных! Слушай, давай разберемся, что это за зверь такой, а то у тебя, я смотрю, глаза уже квадратные от одного слова.

Представь себе, блядь, что твоя база данных — это твоя старая, любимая квартира. Живешь ты в ней, всё на своих местах: диван тут, холодильник там, а на балконе, как водится, хлам. И тут тебе приспичило сделать ремонт. Стенку передвинуть, дверь в другом месте сделать, или, хуле там, кондиционер новый впихнуть. Вот миграция — это и есть этот самый ремонт, но такой, чтобы ты не выносил нахуй всю мебель на улицу, а аккуратненько всё переставил, пока живешь внутри. Данные — это твои вещи, их терять низя.

Зачем это, спрашивается, надо? Да всё просто, ёпта!

• Новое поле в таблицу добавить — это как в комнате новую розетку врезать. Без неё уже жить не можешь, а раньше как-то обходился.
• Таблицу переименовать — ну, типа, переклеить табличку на двери. Была «Кладовка», стала «Кабинет для медитаций и хранения банок с огурцами».
• Тип данных поменять — это вообще пиздец. Раньше в ячейке «Возраст» было просто число, а теперь ты хочешь хранить дату рождения и высчитывать возраст на лету. Ну, делов-то!
• Нормализовать схему — это когда ты берешь весь хлам с балкона, сортируешь его по коробкам, подписываешь и ставишь на стеллаж. Бесит, зато потом легче искать.

А в Core Data, сука, миграции бывают двух сортов, как водка: простая и выдержанная.

1. Легковесная миграция (Lightweight Migration). Это когда ты такой: «О, я всего-то новую optional-полку в шкаф добавил!». Core Data смотрит на это и говорит: «Да похуй, я сам всё сделаю». Автоматически, блядь. Главное — флажки правильные воткнуть.

   let options: [AnyHashable: Any] = [
       NSMigratePersistentStoresAutomaticallyOption: true, // «Да, мигрируй, не спрашивай»
       NSInferMappingModelAutomaticallyOption: true // «И догадайся сам, как это сделать»
   ]
   // Эти две волшебные строчки — как разрешение от жены на ремонт. Главное — потом не охуеть от результата.

2. Тяжёлая миграция (Heavyweight/Mapping Migration). А вот это уже, сука, капитальный ремонт с перепланировкой. Снос несущей стены, перенос санузла. Удалил колонку? Поменял тип у non-optional поля? Да ты, блядь, садомазохист! Тут Core Data руками разводит: «Сам, мудила, придумал — сам и расхлёбывай». Придётся тебе вручную создавать Mapping Model (файлик .xcmappingmodel). Это как подробнейший дизайн-проект для прораба (Core Data), где расписано, что куда и как переезжает. «Вот этот старый диван (поле oldName) теперь будет называться «новый угловой диван» (поле newName) и стоять в гостиной (новая сущность)».

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

• Версионируй модель, ёбта! Каждое изменение — новая версия .xcdatamodel. Не лезь в старую, как слон в посудную лавку. Создал новую, поправил там, и спи спокойно. Это твои контрольные точки, чтобы откатиться.
• Бэкап, блядь, бэкап! Перед тем как на проде эту адскую машину запускать — сохрани базу как есть. Мало ли что. Это как сфоткать квартиру до ремонта, чтобы потом в суд подать на прораба.
• Тестируй до одури! Не на двух записюльках, а на реальных данных, максимально похожих на боевые. Запусти миграцию, проверь, что всё на месте, ничего не проёбано и не перепутано. Иначе получишь, как я однажды, приложение, где у всех пользователей вместо имени было 0xDEADBEEF. Красиво, но нихуя не понятно.

Вот и вся наука. Не так страшен чёрт, как его малюют. Главное — не делать резких движений и всегда иметь план «Б», а лучше — план «Нахуй, я передумал, откатываемся».