Стварэнне базовага стану існуючай базы дадзеных у Prisma без запуску каманды migrate reset

Prisma Migrate працюе з базайнам дадзеных, які вже маюць табелі і даныя, і ў большай часткі першы запуск npx prisma migrate dev завершваецца паведамленням пра адхылэнне і пропозыцыяй перазначыць усё. Гэта паведамленне означае, што базайн дадзеных мае структуру, пра якую історыя міграцый Prisma нічога не ведае. Акцептаванне гэтай пропозыцыі ведае до выдалення вашых дадзеных. У гэтым кяліках пояснюецца, чаму выходзіць канфлікт, чаму перазначэнне практычна ніколі не ёсць правым рашэнням для важлівага базайна дадзеных, і як стварыць базовую версію існуючага схематызму, каб Prisma выкористоўваў яе як пачатковую точку і прыменяў змены толькі адтуды.

Чаму Prisma фіксуе канфлікт

Prisma Migrate зберагае два відліки эвалюцыі вашай схемы: файлы міграцыйніх дзеянняй у падзе prisma/migrations і табелю пад назвай _prisma_migrations у базе даных, якая паказвае, калькі з тых файлоў былі застосаваны. Калі вы запускаеце migrate dev, Prisma пераглядае історыю міграцыйніх дзеянняй у тэмпаратарной „тэневай“ базе даных і парабягае рэзультаты з рэальной базай даных.

Якщо рэальная база даных вялічыць табелі, якія не былі створаны жадной міграцыёй, напрыклад, таму што яна была створана вручную, іншым інструментам або ранейшай версіяй прыложэння, тады гэтыя два варыянты не збігаюцца. Prisma называе гэта „дріфтам“. Паколькі migrate dev ёсць команда для разработкі, яе стандартны спосаб выправлення — це стерць базу даных і перзначыць яе на адной з історыі міграцыйніх дзеянняй, таму ёна пропануе перзначэнне. Гэта разумна для тымчасовай локальной базы даных, але разрушаючая для всіх інших варыянтаў.

Якщо вы хочаце большэй информацыі пра тое, як база дадзеных Shadow участвуе ў гэтым парабяранні, адзірніце Prisma's shadow database and naming mismatches.

Чаму migrate reset — гэта неправильны спосаб рашэння

npx prisma migrate reset удаляе базу дадзеных, або кожную табелю ў яе схеме, стварае яе занова на аднойчынку міграцый і запускае скрыпты для заполнення. Усі існуючыя рэкі трапляюцца. У базе дадзеных з рэальнымі пользователямі, замовленнямі чы ўтварэннямі гэта не рашэнне канфлікту, а втрата дадзеных.

Кращы спосаб — не чапацца за базу дадзеных, а замест таго аднавіць вярсію Prisma пра стан рэчаў. Для гэтага трэба зафіксаваць текущую структуру як першую міграцыю і паведаміць Prisma, што гэтая міграцыя вже ўвядзена.

Этапы стварэння базовага стану

Шаг 1: Анаіз існуючай базы дадзеных

Заўядзіце npx prisma db pull. Prisma падключаецца да базы дадзеных, чытае ў яй таблицы, столбцы, індэксы і зв’язкі, а потым запісвае адпаведныя модэлі ў schema.prisma. Пасля гэтага шагу файл схемы точна описвае базу дадзеных такой, якая ёй є.

Шаг 2: Стварыць базовую міграцыю без ўжывання яе

Створыце папку для базовага стану, напрыклад prisma/migrations/0_init. Прымак 0_ дапамагае яй павярнуцься раней за ўсія пазнейшыя міграцыі з часовымі пазначкамі. Потым створыце SQL-код, які будзе ствараць чырговую схему з нічога, і запісаце яго там, выкарыстоўваючы npx prisma migrate diff --from-empty --to-schema-datamodel prisma/schema.prisma --script > prisma/migrations/0_init/migration.sql. У новейшых версіях Prisma пазнака цэлі можа называцца --to-schema, таму пераканайцеся, як гэта выглядае у вашай версіи, вызначыўшы npx prisma migrate diff --help.

Эты крок мае важнае значэнне, таму што ён стварае файл міграцыі без вплыву на базу дадзеных. Частая памылка — запуск команды npx prisma migrate dev --name baseline у гэты момент. У разе базы дадзеных, якая вже мае табелі і не мае історыі міграцый, гэтая команда выкрывае той самы адхіл, як і раней, і прасіць прызначыць все зноў, што якраз і ёсць тое, чаго вы намагаецеся ухіліцца. SQL-код базовага стану ніколі не трэба выконваць проты існуючай базы дадзеных, таму што ў яе вже існуюць табелі.

Крок 3: Прызначыць базовы стан як застосаваны

Запусціце npx prisma migrate resolve --applied 0_init. Аргумент — гэта назва папкі міграцый. Якщо папка была створана з часовым меткам, напрыклад 20250101120000_baseline, вам неабходна запісаць саме гэту повную назву, а не проста baseline.

Этыя каманды не выконваюць жадных SQL-запытоў да вашых тэблей. Яна вводзіць рядок у _prisma_migrations, па якому фіксуецца, што базовы стан быў застосаваны. Па сутнасці вы правяліе прыметнік Prisma, ўнаследке чаго ён прыймае ныякі структуру як намеровую і правядзячую.

Як гэта рашае конфлікт

Гэта супамінае конфлікт злучэння ў Git: калі ваша гілка не мае комітав, якія вже ў галоўнай гілцы, вы апдэйтуеце гілку, а не вычысвале галоўную. Хутчэй, база дадзеных ўжо апдэйтаваная, і вы прыбліжаеце історыю Prisma да яе рэальнага стану.

Пасля таго, як базовы стан зафіксаваны, наступны запыт npx prisma migrate dev павторна выконвае 0_init у „ценавай“ базе дадзеных, атрымвае тую ж структуру, што і ў рэальной базе дадзеных, і не выяўляе жадных разніц.

Чаму гэта важна для большых баз дадзеных

Базаванне дае максымальны эфект, калі база дадзеных зберагае вельмі большы об’ём дадзеных. Калі базаванне зафіксавана ў _prisma_migrations а ўзорк базы дадзеных супараднае з рэальной, Prisma не чыніць змян у існуючых табліцах і рэкантажах, а прыменяе толькі новыя змяны, такім чынам табліца users застаецца недыяранай.

Згадайце калькі практычных пунктав:

• Выконайце migrate resolve --applied аднойчы для кожнай існуючай среды, такой як стэйджінг і працоўная среда, адколькі кожная база дадзеных мае свою табліцу _prisma_migrations.
• У працоўнай средзе прыменяйце пазнейшыя міграцыі за дапамою npx prisma migrate deploy, а не migrate dev, якая падходзіць толькі для розрабоцтва.
• Зберажыце папку з базаваннем у системе керування версіямі, ўпэўніўшыся, што кожны разрабоцкі і задачы CI будуць выкарыстоўваць аднойчыны пачатковыя данні.

Ключовыя выводы

• Апавяшчанне пра дрыф у існуючай базе дадзеных значыць, што історыя міграцый Prisma не ўтваралася, а не тое, што сама база дадзеных некоректная.
• Скасаванне наладжэння ведае да выдалення дадзеных; трэба спрыяць яго як інструмент толькі для тымчасовых локальных баз дадзеных.
• Ствараць базовы стан можна праз аналіз за дапамою db pull, генераванне SQL-кода за дапамою migrate diff --from-empty і запісванне яго за дапамою migrate resolve --applied.
• Не варыта использоваць migrate dev для стварэння базовага стану на адмініструючай базе дадзеных, таму што гэта таксама выклікае запит на скасаванне наладжэння.
• Пасля стварэння базовага стану Prisma керуе толькі інкрементальнымі зменамі, а існуючыя дадзеныя застаюцца недастрымленымі.