#iOSКомпас 🧭1️⃣5️⃣0️⃣ Завдання 150Як проводити міграцію в SwiftData без втрати даних?Пробачте за кілька днів тиші, Капітан святкував День Народження, але ми повертаємось! Доброго здоровля мої любі друзі. З вами ваш незмінний iOS розробник Сергій з @badlinkschannel.Коли в застосунку змінюється модель даних, міграція стає тим ще головняком. Особливо якщо користувачі вже накопичили тонни інформації, яку не можна просто викинути. SwiftData пропонує кілька способів розрулити це: від автоматичних легких міграцій до повністю ручних, де розробник контролює кожен крок. Розбираємося, як не наступити на граблі.🔣 Версіонування з першого дня:Будь-яку роботу з даними краще одразу будувати з версіонуванням. Навіть якщо зараз у вас одна-єдина модель, закласти VersionedSchema - хороша ідея. Це створює стабільну точку відліку. Потім, коли з'являться зміни, буде зрозуміло, звідки і куди мігрувати.Зазвичай схемам дають номери версій: V1, V2, V3. У коді вони живуть як окремі enum зі списком моделей та ідентифікатором версії. А для зручності в основному коді часто використовують typealias, щоб щоразу не писати щось на кшталт ExerciseSchemaV5.Exercise.Нову версію варто заводити перед кожним релізом, у якому змінюються моделі. Навіть якщо змін кілька, вони всі можуть увійти в одну версію схеми. Головне - щоб користувачі, які пропустили пару оновлень, могли доїхати одразу в актуальну версію без втрати даних.🔣 Коли SwiftData справляється сама:Є зміни, які SwiftData вміє обробляти автоматично. Серед них:➖ Додавання опціонального поля - старі об'єкти просто отримають nil.➖ Видалення поля - дані цього поля загубляться, але сама міграція пройде спокійно.➖ Перейменування поля - якщо вказати @Attribute(originalName:).У таких випадках можна або взагалі не писати міграційний план, або додати його для порядку, але використати легкий етап .lightweight. План може стати в пригоді, коли хочеться чітко контролювати всі кроки й нормально це тестувати.🔣 Коли потрібна ручна робота:Легка міграція перестає бути достатньою, коли нове поле треба не просто додати, а ще й осмислено заповнити для старих записів. Те саме - коли треба перетворити дані: змінити тип, розбити одне поле на кілька, змерджити сутності, почистити дублікати.У таких випадках пишеться SchemaMigrationPlan з кастомними етапами. У кожного етапу є дві фази:➖ willMigrate - виконується до застосування нової схеми й працює зі старими даними, наприклад тут можна почистити дублікати.➖ didMigrate - виконується після застосування нової схеми, і тут уже доступні нові моделі та можна доробити дані під нову структуру.Наприклад, якщо в новій версії з'являється поле createdAt, безпечніше або дати йому дефолтне значення, або спочатку зробити його опціональним, а вже потім окремим кроком заповнити для старих об'єктів.#️⃣ сМіграції в SwiftData - це не про героїзм, а про акуратність. Якщо з самого початку закласти версіонування й продумувати зміни, більшість проблем вирішуються або автоматично, або невеликими кастомними етапами. А для найскладніших випадків завжди можна розбити задачу на кілька версій, щоб не переписувати все за один раз. Головне - не забувати тестувати на реальних даних, а не тільки на порожній базі в симуляторі.@Zatishna_Galera