Feature/prisma schema migration#16
Conversation
- Crear modulo problems siguiendo el mismo patron que auth (SQL plano + pg) - Agregar tabla problems con restriccion de unicidad en slug - Implementar GET /problems protegido con authGuard - Retornar shape estable para el frontend (id, slug, title, difficulty, short_description, acceptance_rate)
- Instalar prisma, @prisma/client y @prisma/adapter-pg - Configurar prisma.config.ts para Prisma 7 (datasource via DATABASE_URL) - Introspectar tablas existentes (problems, users) y renombrar a convencion idiomatica (Problem, User con @@Map) - Generar migracion baseline y marcarla como aplicada sin perdida de datos - Instanciar cliente de Prisma en src/database/prisma.js (no usado aun en repositories) - Las consultas siguen siendo SQL plano via pg, sin cambios en auth/problems repositories Alcance intencional: solo manejo de esquema y migraciones con Prisma por ahora, las queries se migraran en un issue futuro
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: e6ce8a3b9c
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| ); | ||
|
|
||
| -- CreateTable | ||
| CREATE TABLE "users" ( |
There was a problem hiding this comment.
In any environment that has already run this service before this commit, src/modules/auth/auth.repository.js creates users automatically with CREATE TABLE IF NOT EXISTS; this new initial Prisma migration uses an unconditional CREATE TABLE "users", so prisma migrate deploy will fail with an existing-relation error before recording the migration. Baseline the existing schema or make the migration compatible with already-created tables instead of recreating users.
Useful? React with 👍 / 👎.
| "id" BIGSERIAL NOT NULL, | ||
| "slug" TEXT NOT NULL, | ||
| "title" TEXT NOT NULL, | ||
| "difficulty" TEXT NOT NULL, |
There was a problem hiding this comment.
When a fresh database is initialized through this Prisma migration, problems.difficulty is created as unrestricted text, while the runtime fallback in src/modules/problems/problems.repository.js creates the same column with CHECK (difficulty IN ('easy', 'medium', 'hard')). Because the app later uses CREATE TABLE IF NOT EXISTS, it will not add the missing constraint after migrations have created the table, so migrated databases accept invalid difficulty values and diverge from the schema the app expects.
Useful? React with 👍 / 👎.
| const { PrismaPg } = require('@prisma/adapter-pg'); | ||
| const env = require('../config/env'); | ||
|
|
||
| const connectionString = `postgresql://${env.db.user}:${env.db.password}@${env.db.host}:${env.db.port}/${env.db.database}?schema=public`; |
There was a problem hiding this comment.
This Prisma client builds its connection from the legacy DB_* variables, while prisma.config.ts runs Prisma CLI and migrations against DATABASE_URL; when those values differ, migrations are applied to one database but Prisma runtime queries another. Use the same source of truth here as the CLI config, or derive one value from the other, so generated clients and migrations target the same database.
Useful? React with 👍 / 👎.
| "engines": { | ||
| "node": "^20.19 || ^22.12 || >=24.0" | ||
| }, |
There was a problem hiding this comment.
The new Prisma client dependency requires Node ^20.19 || ^22.12 || >=24.0, but the project documentation still tells contributors that Node >=20 is sufficient. On Node 20.0–20.18, which is currently advertised as supported, installs fail under engine-strict and the Prisma runtime is outside its supported engine range, so either raise the documented/package engine floor or choose a Prisma version compatible with the existing Node range.
Useful? React with 👍 / 👎.
| @@ -0,0 +1,24 @@ | |||
| const { PrismaClient } = require('@prisma/client'); | |||
There was a problem hiding this comment.
On a clean checkout, this module can be imported before any generated Prisma Client exists: the commit adds @prisma/client but no prisma generate build/postinstall step, and Prisma 7 migrations no longer generate the client automatically. Any later route/repository that switches to this module after npm ci will fail at startup until someone has run generation manually, so wire prisma generate into the install/build flow or commit/import from the configured generated output.
Useful? React with 👍 / 👎.
… manual table initialization with Prisma migrations
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: acafc3f84c
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| path: "prisma/migrations", | ||
| }, | ||
| datasource: { | ||
| url: env("DATABASE_URL"), |
There was a problem hiding this comment.
When a clean CI/Docker install runs npm ci/npm install without DATABASE_URL (common when the DB URL is only injected at runtime), the new postinstall runs prisma generate, and Prisma config docs state that env() throws when the variable is undefined and every CLI command loads prisma.config.ts, including generate. This makes dependency installation fail before the app can be built even though client generation does not need a live database URL; use a non-throwing process.env fallback here or move generation to a step that has the secret.
Useful? React with 👍 / 👎.
2 participants
Se integró Prisma al proyecto según lo hablado en la reunión (Esquemas y Cliente).