Base de datos
PostgreSQL 16 vía Prisma, ~56 modelos, y cómo se mapean las tablas de FreeRADIUS.
Valwisp usa PostgreSQL 16 a través de Prisma ORM. El schema completo vive en
apps/valwisp-api/prisma/schema.prisma (~56 modelos).
Comandos
npm run db:generate # prisma generate (tras cambiar el schema)
npm run db:migrate # prisma migrate dev (crear + aplicar migración)
npm run db:migrate:prod # prisma migrate deploy (producción)
npm run db:seed # ts-node prisma/seed.ts
npm run db:studio # GUI de PrismaBinarios de Prisma: native + linux-musl-arm64-openssl-3.0.x (para el contenedor de
producción).
Modelos clave
Los modelos de negocio centrales (Client, InternetService, Plan, Router,
Invoice, Payment, Ticket, Installation, ...) siguen todos la regla de
multi-tenancy: columna tenantId obligatoria.
Tablas de FreeRADIUS
Un caso particular: los modelos RadCheck, RadReply, RadUserGroup, RadGroupReply,
RadAcct y RadPostAuth están @@map-eados a los nombres clásicos de tabla de
FreeRADIUS (radcheck, radreply, etc.), para que el servidor FreeRADIUS
(infra/freeradius/) pueda leer/escribir directo sobre el mismo Postgres de Valwisp sin
una base de datos MySQL separada. Ver
Implementadores → FreeRADIUS para el estado real de
uso de estas tablas.
El único uso de
mysql2en todo el monorepo está enapps/valwisp-agent, para migración de lectura de la base MySQL legacy de Mikrowisp — no tiene relación con RADIUS.
Migraciones en producción
Las migraciones no corren automáticamente al desplegar — el contenedor levanta con
prisma db push desde el estado actual del schema. Esto significa que cualquier columna
NOT NULL sin default puede tumbar la API entera al desplegar, y cualquier backfill
escrito dentro de un migration.sql es código muerto en producción (nunca se ejecuta). Al
agregar una columna requerida a un modelo con filas existentes, dale un default o
hazla opcional primero.