2.9 KiB
Migraciones PostgreSQL
V1 crea diez tablas: flow_definition, request_type, request_instance, execution, action_execution, document_reference, audit_entry, admin_audit, request_creation_idempotency y reconciliation_resolution. Incluye FKs, checks JSONB e índices de cola, leases, consultas e idempotencia. El índice único de ejecución activa incluye RECONCILIATION_REQUIRED.
V2 protege versiones publicadas/retiradas e históricos contra UPDATE, DELETE y TRUNCATE. Editar borradores requiere incrementar revision; publicar requiere checksum y fecha. La validación semántica y auditoría atómica de publicación corresponden a T06, no a estos triggers.
El esquema del servicio y su historial Flyway es orchestrator.
${orchestratorSchema} permite ejecutar las mismas migraciones en esquemas de
prueba. No editar migraciones aplicadas; añadir versiones consecutivas.
Flyway clean está deshabilitado. La base debe existir previamente.
Roles
El migrador crea el esquema y aplica migraciones. Configurar sus credenciales en DB_MIGRATION_USERNAME y DB_MIGRATION_PASSWORD. Si se omiten, se usan DB_USERNAME/DB_PASSWORD por compatibilidad con desarrollo. Ese fallback no representa separación de privilegios.
El administrador provisiona por separado un usuario de aplicación sin privilegios administrativos ni pertenencia al propietario. Tras migrar, el propietario concede permisos al usuario existente:
SELECT orchestrator.grant_runtime_access('orchestrator_app'::name);
Usar ese usuario en DB_USERNAME/DB_PASSWORD, conservando el migrador separado. La función no crea usuarios/contraseñas ni usa SECURITY DEFINER. Rechaza roles administrativos o miembros del propietario. El migrador aprovisiona request_type; el runtime puede consultar y cambiar su activación. Auditoría, documentos y resoluciones admiten SELECT/INSERT; el runtime no recibe DDL, TRUNCATE ni acceso al historial Flyway. Revisar también permisos heredados: la función concede permisos, no elimina concesiones ajenas. Un superusuario/propietario puede desactivar deliberadamente los triggers; el runtime debe usar otro rol.
Pruebas
DatabaseMigrationIT aplica V1/V2 desde cero en t03_<UUID> y elimina únicamente
ese esquema al finalizar. Verifica constraints, permisos, rollback, concurrencia
y SKIP LOCKED. El rol NOLOGIN de prueba se crea dentro de una transacción y se
revierte con ROLLBACK. El usuario de pruebas necesita crear esquemas y roles.
./mvnw clean verify usa Testcontainers postgres:9.6.24 y requiere Docker.
La alternativa externa exige una URL terminada exactamente en /orquestador_test;
ver RUNBOOK.
T10 agrega V3__action_effect_checkpoint.sql sin modificar V1/V2. La columna effect conserva clasificación confiable para recuperación; checkpoints legados se consideran NON_IDEMPOTENT_WRITE. Grants V2 sobre la tabla cubren la nueva columna; no hay roles ni secretos nuevos. Ver WORKER.md y ADR-014.