¿Cómo obtener una ruta migratoria para volver a ejecutar la migración?

Question

NUESTRO SISTEMA

estamos tratando de poner las migraciones como archivos .sql bajo control de versiones. Los desarrolladores escribirían un archivo VN __ *. Sql, se comprometerían con el control de versiones y un trabajo que se ejecutaría cada 5 minutos migraría automáticamente a una base de datos Dev y Test. Una vez que el cambio demostró no causar problemas, alguien más ejecutaría un trabajo manual para ejecutar la migración en Producción.

mi problema:

que tenía una migración de demostración que creó unas pocas mesas. Comprobé V4__DemoTables.sql en el control de versiones en mi PC.

En nuestra caja de Linux, un trabajo que se ejecuta cada 5 minutos extrajo el nuevo archivo del control de versión, luego ejecutó el archivo flyway.sh. Detectó el archivo y lo ejecutó.

Pero el archivo .sql tenía un error tipográfico. Y estamos usando Neteeza, que tiene problemas con la ruta migratoria que automáticamente ajusta una migración en BEGIN TRAN ... END TRAN. Entonces la migración creó 2 tablas, luego abortó antes de la tercera.

No hay problema, pensé. Solté las 2 tablas que creó el archivo .sql. Comprueba V4__ fuera del control de la versión, solucionó el error tipográfico y lo volvió a enviar.

Cinco minutos después se extrajo la actualización pero flyway se queja de que la suma de comprobación no coincide. Por lo tanto, NO ejecutará el archivo V4__DemoTables.sql actualizado.

¿Cómo obtengo Flyway para aceptar el archivo actualizado y actualizar la suma de comprobación en el archivo SCHEMA_VERSION en caso de un error tipográfico?

Leyendo los documentos parece que los desarrolladores sugieren que debería haber creado un nuevo archivo V4_1_DemoTables.sql con el arreglo. Pero esto habría chocado con los comandos en el archivo V4__, así que esto parecía equivocado.

Así que aquí es lo que los documentos implican que tengo que hacer:

• Dejar V4__ como la migración 'exitoso' según la tabla SCHEMA_VERSION.

  Cree V4_1_ para eliminar las tablas que se crearon antes de la línea de error en V4__.

  Crear V4_2_ que tiene la corrección de error del archivo original para hacer todo el trabajo real.

¿Es esto correcto?

Answer 1

Si la migración completa con éxito, pero algunos de los objetos de base de datos no están del todo bien (error tipográfico en nombre de la columna, ...), hacer lo que ha dicho y empujar un guión seguimiento que la fija (renombrar columna, ...).

Si la migración falla , y no se ejecuta en una base de datos con la transacción DDL, el DB debe ser limpiado manualmente .Esto significa:

• Volviendo los efectos de la migración en el DB
• Extracción de la versión de la tabla de SCHEMA_VERSION y marcado la anterior como corriente

Este segundo paso será automatizado en el futuro con el introduction of the flyway.repair() command.