Siempre que trabajamos con bases de datos, estamos con el nudo en la garganta cada vez que modificamos el esquema de ésta. Pues bien, Flyway es muy útil, ya que mantiene una history de los cambios que se han ido realizando en ésta, de forma que si una persona se une al proyecto más tarde, puede entender como éste ha ido evolucionando y modificar la BD sin miedo a romperla. (Además, de que siempre se puede volver a la versión anterior). Para ello, Flyway trabaja con ficheros de migración en los que se define/modifica el esquema.

Nuestro ejemplo:

Tenemos un proyecto de postgreSQL con flyway en Java Spring Boot con una base de datos ya definida desde el principio del proyecto en la migración V1_0_0__Initial.sql, como:

CREATE TABLE email_confirmation
(
    id              SERIAL PRIMARY KEY NOT NULL,
    email           VARCHAR NOT NULL ,
    hash            VARCHAR NOT NULL UNIQUE ,
    created_on      TIMESTAMP
);

CREATE TABLE credentials
(
    id              SERIAL          PRIMARY KEY NOT NULL,
    email           VARCHAR         UNIQUE,
    hashed_password VARCHAR         NOT NULL,
    email_confirmed BOOLEAN         NOT NULL,
    email_confirmation_id INTEGER   NOT NULL,
    FOREIGN KEY (email_confirmation_id) REFERENCES email_confirmation(id)
);

CREATE TABLE roles
(
    id              SERIAL          PRIMARY KEY NOT NULL,
    name            VARCHAR(50)     UNIQUE NOT NULL
);

Lo que ha ocurrido es que a medida que el proyecto ha ido creciendo, han ido surgiendo nuevos features, lo que ha hecho que la estructura de la BD deba modificarse.

Pues bien, hoy os voy a mostrar lo que he aprendido hoy a la hora de modificar la BD con un nuevo fichero de migración de Flyway.

En primer lugar, es necesario saber que:

1. Estos ficheros se guardan en el directorio del proyecto de Spring “resources” en otro directorio llamado “db.migration”.

2. Los nombres de estos ficheros deben tener una sintaxis muy concreta:

• Prefix: V indica que se va a crear una versión nueva.
• Version: Número de la versión con puntos o subrayado ( _ ) separado tantas veces como desees.
• Separator: __ (dos subrayados).
• Description: Símbolo de subrayado entre palabras.
• Suffix: .sql

Por ejemplo:

V1_0_8__Add_Email_Recovery_Password.sql

(Atención: la V debe ser mayúscula. Si no respetáis esa sintaxis, podréis pasaros fácilmente un par de horas intentando encontrar la razón por la que PostgreSQL no os coge la nueva migración. Lo sé por experiencia)

En segundo lugar, es importante saber que en ocasiones, al intentar actualizar la BD con una nueva migración, no se actualiza automáticamente en la tabla (que se crea automáticamente) del historial de versiones (flyway_schema_history).

Para ver si ése es el caso, lo ideal es que vayáis al esquema de la base de datos en el IDE (Intellij en este caso) y veáis qué contiene esa tabla:

Esquema de la BD de mi proyecto

Contenido de mi tabla (flyway_schema_history)

Pues bien, en mi caso, el último registro de esta tabla debería corresponder a la última migración (V1_0_8__Add_Email_Recovery_Password) que contiene los cambios más recientes que he hecho.

¿Cómo podemos “forzar” a la tabla del historial de flyway a incluir la última versión?

Pues debemos borrar las tablas de la BD, incluyendo la tabla del historial de Flyway, y volver a ejecutar nuestro proyecto. En ese momento, Flyway volverá a crear todas las tablas incluyendo la tabla del historial con la última migración en ella. Lo podéis ver en la consola de ejecución, la cual os mostrará todas las migraciones que se van cargando hasta poner que se han aplicado todas las migraciones que esperabais:

Y si lo queréis comprobar bien, volved a ir a la BD y abrid la tabla flyway_schema_history, y os mostrará todas las migraciones aplicadas con la última incluida: