How best to handle Flyway with embedded DB for integration tests?

Question

I have an existing application that I recently started to use Flyway with, and that's been working pretty well, for the most part.

I've been running a local MySQL DB for my development environment, which matches up with what's used in QA and Prod.

However, I want to be able to run at least some integration tests directly against an embedded database, like H2. I had naïvely hoped that, since MySQL seems to wrap (most?) of its special statements in special comments (eg /*! SET @foo = 123 */; ).

However, it seems that when Flyway parses my first migration, it ends up skipping ALL of my CREATE TABLE statements, so that it only ends up applying an INSERT of some reference data, which fails since the tables never got created...

I've tried turning up the logging level, but I'm having no luck seeing any indication of why Flyway has just skipped the first 2228 lines of my migration...

Does anyone have any advice on how to best handle this situation? I've tried liberally sprinkling some /*! ... */ /*! ... */ comments over things like ENGINE=InnoDB , but it seems Flyway still skips those statements.

Am I best off just reorganizing and duplicating most, if not all, of my migrations using database-specific flyway.locations , as referred to in the FAQ ? Or is there some way I can make minimal changes, at least to what I got from my initial mysqldump of the existing DB that I used for the baseline migration, to maintain a single migration for both databases?

Or... is there a recommended way to run my integration tests against MySQL instead? I came across MySQL Connector/MXJ , but that seems to be discontinued...

Answer 1

It is the old problem "There is no SQL standard in existence".

Flyway is probably skipping your statements because they contain syntax H2 does not understand. Please take a look at the H2 docu to figure out what part of the H2 CREATE TABLE syntax is different to the MySQL CREATE TABLE syntax. If you are lucky there might even be a syntax variant that both databases understand.

If not you would have to separate the SQL statements into two different locations. Keep in mind that you can tell Flyway multiple locations at the same time. So you can have a core of common scripts and only move the parts that differ in db specific files. You then start your local tests with common + H2 as location and your production scripts with common + MySQL.

If you are using a technology that can create the tables for you (like Hibernate) you might want to not use Flyway when executing tests locally to avoid to have to take care of two sets of migration files. Just let your test generate the latest version of the database. This might also advantages as it could be quite a lot faster then running a lot of migration scripts later down the line (say in a few years).

You will have to run some integration tests against a real MySQL database as as you have seen H2 might behave quite different. That way you might consider side-loading your database with some data using what ever backup solution is available for your database. This might be faster than trying to initialize the database from scratch using Flyway. (Again done the line you will not want to run years of migration scripts before testing.) You probably want to only test your latest set of scripts anyway as the older ones did work when they where new (and Flyway will ensure they have not been changed).