Posteriormente a buscar en diferentes repositorios y sitios al concluir encontramos la respuesta que te compartimos más adelante.
Solución:
Puede probar el modo “updateSQL”, se conectará a la base de datos (verifique sus derechos de acceso), adquirirá el bloqueo de la base de datos, generará/imprimirá sentencias SQL para ser aplicadas (según el estado de la base de datos y sus conjuntos de cambios de liquibase actuales) y también imprimirá la identificación de chageset que falta en el estado actual de la base de datos y suelte el bloqueo de la base de datos.
Lamentablemente no.
De forma predeterminada, Liquibase confirma la transacción ejecutando todas las declaraciones de un conjunto de cambios. Supongo que las rutas de migración que tiene en mente generalmente involucran más de un solo conjunto de cambios.
La única forma en que puede modificar el comportamiento de la transacción es el runInTransaction attribute Para el falsedeshabilita efectivamente la administración de transacciones, es decir, habilita el modo de confirmación automática como puede ver en ChangeSet.java.
Creo que esta función podría ser una valiosa adición a Liquibase, así que abrí una solicitud de función: CORE-1790.
Creo que su respuesta es “no admite ejecuciones en seco”, pero el problema es principalmente con la base de datos y no con liquibase.
Liquibase ejecuta cada conjunto de cambios en una transacción y lo confirma después de insertarlo en la tabla DATABASECHANGELOG, por lo que, en teoría, podría anular la lógica de liquibase para revertir esa transacción en lugar de confirmarla, pero se encontrará con el problema de que la mayoría de los SQL ejecutados por liquibase son automáticos. -comprometerse.
Por ejemplo, si tuviera un changeSet de:
...
Lo que se corrió es:
START TRANSACTION
CREATE TABLE NAME ...
INSERT INTO DATABASECHANGELOG...
COMMIT
pero incluso si cambió el último comando a ROLLBACK, la llamada de creación de tabla se confirmará automáticamente cuando se ejecute y lo único que realmente se revertirá es INSERT.
NOTA: hay algunas bases de datos que revertirán DDL SQL, como postgresql, pero la mayoría no lo hace.
Los comandos INSERT/UPDATE se ejecutarían en una transacción y podrían revertirse automáticamente al final, pero liquibase no tiene un comando postCondition para realizar la verificación en la transacción del estado que sería necesario. Esa sería una característica útil (https://liquibase.jira.com/browse/CORE-1793), pero incluso no sería utilizable si hay etiquetas de cambio de confirmación automática en el conjunto de cambios. Si agregó una condición posterior para crear el ejemplo de tabla anterior, la condición posterior fallaría y la actualización fallaría, pero la tabla aún estaría allí.
Si guardas alguna incertidumbre y forma de avanzar nuestro división te proponemos añadir una acotación y con mucho placer lo observaremos.