Ves al contingut
Tornar al blog

Prisma en producció: revisa les migracions abans de modificar una base amb dades

Distingeix una base buida d’una d’existent, revisa l’SQL i comprova dades, restriccions i permisos abans d’aplicar migracions Prisma.

  • Prisma
  • PostgreSQL
  • IA

Una aplicació creada amb IA pot funcionar amb una base local i fallar en publicar-la. Crear taules en un altre servidor, traslladar els registres i modificar l’esquema d’una base que ja conté dades són tres operacions diferents. Una migració de Prisma no copia automàticament les files del teu ordinador a producció.

Aquesta guia està preparada per a Prisma 7.10.0, amb la versió fixada al projecte. La documentació actual també descriu ordres de Prisma 8: comprova la versió instal·lada abans de copiar una recepta. L’assaig local descrit a continuació ha acabat; no demostra integració nativa a Hostbrid.

Primer identifica quina base modificaràs

Si el destí és buit i tens un historial de migracions revisat, pots aplicar-hi aquest historial. Si ja hi ha taules o dades, revisa com es va crear l’esquema i si Prisma té un historial que hi coincideixi. L’error P3005, «database schema is not empty», no es resol esborrant una base que necessites conservar.

Una base existent pot requerir un baseline: una migració inicial que representa l’esquema existent i es registra com a aplicada després de verificar aquesta correspondència. No marquis qualsevol fitxer com a aplicat per amagar un error. Una marca incorrecta deixa l’historial i l’esquema real en estats diferents i pot traslladar el problema al lliurament següent.

Si també vols portar dades des del teu equip, prepara una operació d’exportació i importació separada, amb versions compatibles i un destí adequat. Verifica qui continuarà escrivint mentre fas el trasllat. Una captura de pantalla amb les taules creades no prova que hagin arribat totes les files, relacions o seqüències.

No facis servir l’ordre de desenvolupament com a lliurament de producció

A Prisma 7, migrate dev genera i aplica migracions en desenvolupament; pot detectar diferències que requereixin un reset. migrate reset elimina les dades. migrate deploy aplica les migracions pendents que ja existeixen: no genera una migració nova ni el client per tu i tampoc verifica totes les diferències de l’esquema.

Això no converteix migrate deploy en una garantia de conservació. Si el fitxer SQL conté un DROP TABLE, una columna eliminada o una transformació equivocada, aplicar-lo pot destruir informació. Revisa el canvi d’SQL i no només el missatge final de l’ordre. Fixar la versió i conservar el lockfile fa que l’assaig sigui reproduïble; no converteix qualsevol canvi en correcte.

Assaja el canvi amb registres que permetin detectar una pèrdua

Treballa sobre una base d’un sol ús que controlis. Inclou registres amb identificadors coneguts, relacions i valors que hagin de sobreviure. Abans i després, compara aquests valors, no només el nombre de files. Dues taules poden tenir el mateix recompte i contenir dades diferents.

Un camp obligatori nou necessita una estratègia per a les files existents. Pots introduir-lo com a nullable, completar els valors mitjançant una transformació explícita i després imposar la restricció quan hagis verificat que no queden nuls. També has de comprovar les restriccions úniques i les claus foranes que necessita l’aplicació.

Torna a aplicar l’historial al mateix destí per comprovar què queda pendent. Aquest resultat no substitueix la revisió de l’SQL, l’assaig de recuperació o la compatibilitat entre la versió anterior i la nova de la teva aplicació. Una còpia que no has restaurat mai no demostra que puguis recuperar el servei.

Decideix des d’on es podrà executar la migració

Una DATABASE_URL conté accés privat; no la incloguis en variables públiques com VITE_, al repositori ni en exemples que comparteixis. El procés que executa la migració ha de poder arribar a la base i disposar dels permisos adequats per als canvis aprovats. L’aplicació en funcionament pot necessitar permisos diferents.

Hostbrid ofereix bases relacionals i descriu una xarxa privada per defecte a la seva pàgina de bases de dades. Comprova com arribarà a aquesta xarxa el procés de migració abans de contractar o connectar un CI extern. Aquesta guia no demostra accés des de qualsevol proveïdor de CI ni una configuració automàtica de Prisma. Consulta els plans vigents i confirma el motor i la connectivitat que necessita la teva aplicació.

Si encara no saps quina part del projecte necessita servidor, comença per triar l’allotjament d’un web creat amb IA. Publicar el frontend i mantenir una base de producció són decisions relacionades que requereixen verificacions pròpies.

Què hem comprovat a l’exemple original

El 8 d’octubre vam assajar 12 casos amb Prisma 7.10.0, Node 22.23.3, npm 10.9.9 i PostgreSQL 16.13 Homebrew en macOS ARM64. El clúster era nou i local, amb dos comptes i dues entrades fictícies. No vam connectar cap base de Hostbrid ni d’un client.

La migració additiva va conservar cada camp original, ID i relació; el backfill va produir els noms esperats. Les restriccions van rebutjar duplicats i referències invàlides. La branca de base existent va reproduir P3005 abans del baseline; un baseline correcte i un diff sense diferències van permetre aplicar l’additiva. Amb un baseline incorrecte, resolve va acabar amb èxit, però el diff va detectar les restriccions absents i l’assaig no va continuar aquella branca.

Vam restaurar el dump en tres bases noves i comparar les dades. En una altra còpia, un DROP COLUMN va acabar amb èxit i va eliminar valors: conservar el nombre de files no era suficient. Afegir una columna obligatòria sense completar les files existents va fallar; el deploy següent va quedar bloquejat. Els resultats negatius eren esperats i només van afectar dades sintètiques.

Vam aturar el servidor i comprovar-ne la parada. Això no prova taules grans, concurrència, temps de bloqueig, PITR, backups de proveïdor ni l’execució de migracions dins de Projects.

Prisma 7 migrate deploy · Prisma 7 baselining

Executa l’assaig en un entorn d’un sol ús

L’exemple original MIT està fixat a la revisió 87a2a843867be8b6244a68fbc50b3919f4d2b82e. Necessita macOS ARM64, Node 22.23.3, npm 10.9.9, PostgreSQL 16.13 Homebrew instal·lat i el port local 55439 lliure. PG_BIN permet indicar el directori dels binaris. No adaptis aquests contraexemples per executar-los contra una base real: el runner crea i atura el seu propi clúster i ignora una DATABASE_URL rebuda.

git clone https://github.com/ocentelles/hostbrid-example-prisma-migrations.git
cd hostbrid-example-prisma-migrations
git checkout --detach 87a2a843867be8b6244a68fbc50b3919f4d2b82e
node --version
npm --version
npm ci --ignore-scripts --no-audit --no-fund
npm run essay

Gestiona els teus webs, servidors i correu.

És gratis i triga un minut.

Mínim 8 caràcters. Ni només números ni una contrasenya comuna.

T’enviarem un correu per confirmar el compte.