Persistencia, transacciones y migraciones
Cómo evolucionan los datos locales y qué preservar al cambiar de versión o diagnosticar SQLite.
Persistencia local#
La base del host es SQLite y se configura mediante TypeORM. Las migraciones se compilan desde db/sqlite-migrations y se incluyen en el empaquetado. La evolución del esquema utiliza ese historial, no una edición manual de tablas desde la interfaz.
El arranque comparte una promesa de inicialización para que las llamadas concurrentes esperen las migraciones. Si estas fallan, el datasource se cierra y el error se propaga. Las escrituras y transacciones se serializan sobre la conexión SQLite para evitar que operaciones independientes se mezclen.
Configuración y diagnóstico#
El datasource intenta habilitar foreign_keys y journal_mode=WAL. El código actual trata la aplicación de esos pragmas como mejor esfuerzo; una comprobación de soporte debe verificar el estado efectivo en lugar de asumirlo. Antes de mantenimiento, la aplicación intenta completar un checkpoint del WAL y cerrar la conexión.
Respaldo previo a cambios de esquema#
Cuando existe una base previa, el arranque prepara una copia de seguridad antes de migrar. Si no hay migraciones pendientes, retira esa copia innecesaria. La retención local está limitada a cinco directorios de copias previas a migraciones. Estos archivos ayudan a una recuperación de versión, pero no sustituyen el respaldo externo del negocio.
Qué conservan los datos del restaurante#
- Rondas y líneas con los precios y opciones resueltos en el host.
- Identificadores de origen y snapshots para que editar el catálogo no reescriba el historial.
- Asignaciones de cuenta que conservan cantidades e importes, incluida la distribución de centavos.
- Trabajos de impresión persistidos con la comanda correspondiente.
- Datos fiscales capturados para mantener la coherencia entre pedido, cuenta y venta.
Migraciones y compatibilidad#
Las migraciones de restaurante incorporan sesiones, integridad móvil, grupos de opciones compartidos, selección por producto, impresión por estación e instantáneas fiscales. Para datos heredados que no guardaban una instantánea, algunas propiedades deben inferirse de la configuración disponible al migrar; eso no reconstruye información histórica desconocida.
La migración de instantánea fiscal no permite eliminar esos datos mediante un down. Su recuperación exige coordinar la versión anterior y un respaldo previo. Toda modificación del esquema debe incluir cobertura de migración, notas de compatibilidad y una estrategia de recuperación probada sobre copias.