Skip to main content

​
Cliente generado fuera de node_modules

prisma/schema.prisma no genera el cliente en su ubicación habitual: apunta a src/generated/prisma, una carpeta que está gitignored. Cada persona que clona el repo (y cada build) tiene que correr npx prisma generate para que esa carpeta exista. Como consecuencia, el código nunca importa desde @prisma/client. Importa siempre desde el cliente generado:

​
Conexión: prisma.config.ts, no la URL a pelo

El bloque datasource de schema.prisma no lleva url. La conexión a la base de datos viene de prisma.config.ts, que carga dotenv/config para leer las variables de entorno. src/lib/prisma.ts tampoco pasa la URL directamente al cliente: la parsea a mano (new URL(DATABASE_URL)) y con sus piezas (host, usuario, contraseña, base de datos, puerto) construye el adapter PrismaMariaDb.
PRISMA_SCHEMA_VERSION, la constante definida en src/lib/prisma.ts, hay que incrementarla cada vez que se añade o se quita un modelo del schema. Si no se incrementa, el HMR de next dev puede reutilizar un client viejo en memoria y las consultas dejan de coincidir con el schema real.

​
Ubicación: User frente a Camello

User tiene city y neighborhood (opcionales): es dónde vive o busca la persona. Se piden en el registro por email, se editan en el perfil y precargan el dónde de la búsqueda. Camello tiene su propia city y neighborhood: es su zona de servicio, la que filtra GET /api/camellos. Son datos distintos y pueden diferir. Editar la ubicación en el perfil solo escribe en User. Al registrar un camello, la ciudad y el barrio se copian también al User, y la migración copió esos valores a los usuarios con camello vinculado que no tenían ciudad.

​
connection() antes de consultar

Los helpers que consultan la base de datos llaman await connection() (de next/server) antes de ejecutar la query. Esto impide que Next.js intente prerenderizar esas páginas en build time: el build de Docker corre con una DATABASE_URL falsa, así que cualquier consulta real durante el build fallaría.