Using Flyway Java Migrations Sparingly

In my previous post I discussed how to use Spring with Flyway and make it possible to inject Spring beans into Java migrations.

Today after fleshing out my migration, I realised that you have to be very careful when using Spring based migrations. The reason for this is that the migration scripts will generally live in your application forever. For DB scripts this isn't too much of an issue as the scripts run in order and should behave consistently. The problem that can arise with the Java approach is if you start using classes from your code base, those classes are basically stuck in your code base now as they are forever referenced in your Java migration which makes deleting and refsctoring these classes very difficult. For my use case I ended up dropping basically all the Spring beans I needed except for one and used the Spring JDBC template that you get by implementing the Flyway SpringJdbcMigration interface. I also created any helper classes as private inner classes to this script.

One workaround to having classes forever in your Java migrations is to comment the internals of these Java migrations out. This should work as Flyway uses null as the checksum for these migrations as specified in the Java doc comment for this interface: "The checksum of this migration (for validation) will also be null, unless the migration also implements the MigrationChecksumProvider, in which case it can be returned programmatically."