Implementa la capacidad de restaurar la base de datos desde
un archivo SQL de backup exportado previamente.
Cambios:
Backend:
- Nuevo endpoint POST /api/debug/import-database.post.ts
- Recibe archivo .sql via multipart/form-data
- Ejecuta el SQL del backup (que incluye DROP y CREATE)
- Reemplaza completamente la base de datos existente
Frontend:
- Nuevo botón verde "📥 IMPORTAR BACKUP"
- Input file oculto con accept=".sql"
- Validación de extensión de archivo
- Confirmación con advertencia clara
- Estado de carga durante importación
Flujo de uso:
1. Usuario hace click en "📥 IMPORTAR BACKUP"
2. Selecciona archivo .sql previamente exportado
3. Confirma que desea reemplazar toda la BD
4. Sistema ejecuta el SQL completo
5. Muestra mensaje de éxito/error
6. Usuario recarga la página
Esto completa el ciclo backup/restore permitiendo
recuperación completa del estado de la base de datos.
El endpoint ahora puede cargar datos de ejemplo en dos escenarios:
1. Cuando se eliminó la estructura completa (DROP):
- Detecta que las tablas no existen
- Ejecuta el schema completo (01_schema.sql)
- Luego carga los datos de ejemplo (02_seed.sql)
2. Cuando solo se eliminaron los datos (TRUNCATE):
- Detecta que las tablas existen
- Limpia los datos con TRUNCATE CASCADE
- Luego carga los datos de ejemplo
Esto hace que el botón "CARGAR DATOS DE EJEMPLO" sea más
robusto y funcione en cualquier estado de la base de datos.
- Agregar botón 'LIMPIAR DATOS' que hace TRUNCATE de tablas sin borrar estructura
- Agregar botón 'EXPORTAR BACKUP' que descarga pg_dump completo de la BD
- Crear endpoint POST /api/debug/clear-data para TRUNCATE CASCADE
- Crear endpoint POST /api/debug/export-database para pg_dump con descarga
- Mantener estructura de botones temporales de debug existentes
- Incluir confirmaciones y manejo de errores apropiados
- Endpoint seed-database ahora ejecuta 01_schema.sql primero
- Luego ejecuta 02_seed.sql
- Resuelve error cuando se presiona seed después de borrar BD
- Schema tiene CREATE TABLE IF NOT EXISTS (idempotente)
Flujo correcto:
1. Borrar BD → DROP TABLE de todo
2. Cargar datos → Crea tablas + inserta datos
Problema: Al hacer TRUNCATE, las tablas quedaban vacías pero existían,
entonces el workflow pensaba que ya estaba inicializada y no recreaba
los datos de ejemplo.
Solución: Ahora hace DROP TABLE (eliminar completamente) para que el
próximo deploy detecte que no existen tablas y las recree con el seed.
Ahora el flujo correcto es:
1. Click en 'BORRAR TODA LA BD' → DROP de todas las tablas
2. Push o redeploy → Workflow detecta que no hay tablas
3. Workflow ejecuta 01_schema.sql y 02_seed.sql automáticamente
⚠️ CÓDIGO TEMPORAL - NO ELIMINAR SIN CONSULTAR ⚠️
Backend:
- POST /api/debug/reset-database - Borra todos los datos
- POST /api/debug/seed-database - Carga datos de ejemplo
Frontend:
- Card rojo con advertencias notorias
- Botones: 🗑️ BORRAR TODA LA BD y 🌱 CARGAR DATOS DE EJEMPLO
- Confirmación antes de resetear
- Estados de loading
- Alertas de éxito/error
Todos los archivos marcados con comentarios muy visibles:
⚠️⚠️⚠️ NO ELIMINAR SIN CONSULTAR A DARIO/DRAGANEL/NUCLEO000 ⚠️⚠️⚠️
Útil para desarrollo y debugging del sistema de trazabilidad.
