import { PrismaClient } from '@prisma/client';
const prisma = new PrismaClient();
async function main() {
const roles = ['ADMIN', 'EDITOR', 'USER'];
for (const role of roles) {
await prisma.role.upsert({
where: { name: role },
update: {},
create: { name: role },
});
}
console.log('Seed-ul s-a rulat cu succes!');
}
main().catch((e) => {
console.error(e);
process.exit(1);
}).finally(async () => {
await prisma.$disconnect();
});Salutare tuturor. Acum vreo trei ani, pe un proiect de fintech destul de stufos, ne loveam zilnic de celebra replică „dar la mine pe local merge”. CI-ul pica random, testele de integrare dădeau erori ciudate de tip Foreign Key constraint, iar baza de date de test era mereu într-o stare incertă. Problema? Nu aveam un mecanism serios de seed-ing. Ne bazam pe niște dump-uri de SQL vechi de 6 luni care nu mai pupau deloc schema actuală.
Prisma a venit cu o soluție destul de elegantă prin prisma db seed, dar dacă nu ești atent, poți să transformi rapid procesul de seeding într-un coșmar de mentenanță. Secretul pentru un CI (Continuous Integration) care nu te lasă la greu stă în două concepte: idempotența și controlul determinist al datelor.
De ce upsert este singura cale
Cea mai mare greșeală pe care o văd la developerii care trec de la SQL pur la Prisma este folosirea metodei create în scriptul de seed. Dacă rulezi npx prisma db seed de două ori, a doua oară o să primești o eroare de tip „Unique constraint failed” pentru că încerci să inserezi aceleași date.
În CI, unde containerele de Docker se ridică și se coboară constant, sau unde vrei să rulezi teste pe o bază de date persistentă, ai nevoie de idempotență. Folosește upsert. Acesta verifică dacă înregistrarea există (după un ID sau un câmp unic) și, dacă da, îi face update (sau nu face nimic dacă îi dai un obiect update gol). Dacă nu există, o creează. Asta îți garantează că scriptul tău poate fi rulat de 100 de ori fără să crape.
Faker-uri și datele deterministe
Când ai nevoie de volume mari de date pentru a testa paginarea sau performanța, @faker-js/faker este de nelipsit. Totuși, există o capcană: dacă generezi date complet random la fiecare rulare, testele tale vor deveni „flaky”. Un test care trece azi ar putea pica mâine pentru că Faker a generat un string prea lung sau un email care nu respectă un anumit format specific.
Soluția este să folosești un „seed” pentru generatorul de random. Dacă setezi faker.seed(123) la începutul scriptului, Faker va genera exact aceleași date la fiecare rulare. Este esențial pentru CI ca mediul să fie reproductibil 1 la 1.
Integrarea în pipeline-ul de CI/CD
Pe proiectul la care lucrez acum, am integrat seeding-ul direct în fluxul de migrare. În loc să rulăm manual comanda, am adăugat-o în package.json sub flag-ul de prisma.seed. În GitHub Actions sau GitLab CI, pașii noștri arată cam așa:
- Ridicăm baza de date (Postgres/MySQL în Docker).
npx prisma migrate deploy– aplică migrările fără să modifice fișierul de lock.npx prisma db seed– populează datele esențiale (roluri, setări de sistem, user de test).
Un trade-off onest aici: seeding-ul masiv încetinește pipeline-ul. Dacă ai mii de înregistrări de creat, nu le face prin Prisma Client una câte una (care e un proces lent, tip row-by-row). Pentru date masive, mai bine folosești prisma.$executeRaw sau încarci un fișier CSV predefinit. Prisma Client e genial pentru developer experience, dar nu e cel mai rapid mod de a popula 50.000 de rânduri într-un CI care vrei să dureze sub 5 minute.
Concluzie
Nu lăsa datele de test la voia întâmplării. Un script de seed bine scris, bazat pe upsert și cu un Faker controlat, îți va salva zeci de ore de debugging pe erori fantomă în pipeline. Dacă ai date de bază (cum ar fi categoriile de produse sau monedele suportate), acestea ar trebui să fie în seed, nu adăugate manual prin interfața de admin.