Flyway: checksums and repeatable Java migrations

Question

I have a problem with repeatable Java migrations in Flyway 4.2.0.

For example I wrote a repeatable Java migration, that creates for every table with a specific column a trigger. The ChecksumProvider for this migration calculates the hashcode of the concatenated names of tables with missing a trigger.

    @Override
    public int getChecksum(Connection conn) throws SQLException {
        return queryTableNames(conn).stream().collect(Collectors.joining(",")).hashCode();
    }

When the list of tables is empty, the hashcode is zero and nothing should be done.
When the list of tables is not empty, the hashcode is different from zero (name it xxx) and for every table a suiting trigger is added to the database. In this case the hascode xxx is written to "schema_version". The next time flyway:info is executed, it shows an outdated migration, because all triggers are present and the new checksum is zero. So I have to do a "flyway:repair" or a additional "flyway:migrate" to get a clean table "schema_version".

Is there a simple opportunity to update the checksum after a Java repeatable Migration automatically?

I examined FlywayCallback.afterEachMigrate, but there is only read-only access to MigrationInfo. Further steps using this approach would use too much flyway internals (i.e. updating "schema_version" separately).

Implementing an own MigrationResolver coupled with a custom MigrationExecutor seems to be too heavy-weight.

Michael Michael · Accepted Answer · 2017-06-30T05:11:57

The definition of the checksum is wrong. The checksum should refer to the current target state.

In the example the method queryTableNames() should return all tables with such a trigger and the migration should complete these tables with the desired triggers.

Flyway: checksums and repeatable Java migrations

1 Answers