Flyway Community Edition carece del comando 'undo' nativo, una funcionalidad reservada a la versión de pago que resulta crítica ante fallos en producción. Este artículo describe una técnica para simular el rollback utilizando únicamente comandos estándar de Flyway, evitando la ejecución directa de SQL mediante drivers externos. La estrategia se basa en la premisa de que Flyway solo permite que los números de versión aumenten y trata su tabla de historial como inmutable. En lugar de revertir una migración, se crea una nueva migración con un número de versión superior cuyo contenido es el inverso lógico de la original. Este proceso convierte el 'undo' en una migración hacia adelante.
Para gestionar esto, se requiere mantener scripts de reversión ('down') paralelos a las migraciones originales. El sistema registra los lotes de migraciones aplicadas en un archivo JSON para identificar qué versiones deben revertirse. Durante el rollback, estos scripts se reetiquetan con nuevas versiones secuenciales superiores al máximo actual y se ordenan inversamente (la última aplicada se revierte primero). Finalmente, se utiliza un callback 'afterMigrate' para eliminar las entradas de las migraciones originales y sus reversores de la tabla flyway_schema_history, restaurando el estado inicial. El uso de la bandera '-group=true' garantiza que todo el proceso sea atómico: si falla cualquier script, Postgres revierte la transacción completa, asegurando la integridad del esquema.