Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

How to store Flyway H2 migrations' history in another schema than PUBLIC?

Tags:

java

h2

flyway

Using Flyway with H2 database, I get out of the box all SQL schema migrations history stored in PUBLIC.schema_version.

I would like to store this table in a dedicated SQL schema FLYWAY, like this: FLYWAY.history.

Reasons for doing so are not to pollute H2 console visually when opening PUBLIC tables, and to avoid any namespace collision.

By modifying the property flyway.table, the name for the history table can be changed.

But using flyway.table=FLYWAY.history does not work. The schema FLYWAY is not created and the table PUBLIC.'FLYWAY.history' gets created instead.

How should one tweak Flyway configuration in order to achieve the expected result?

like image 946
Christian MICHON Avatar asked Jul 27 '15 12:07

Christian MICHON


People also ask

Where are Flyway migrations stored?

Flyway automatically discovers migrations on the filesystem and on the Java classpath.

Does Flyway migrate data?

Flyway is an open-source database migration tool. It strongly favors simplicity and convention over configuration. It is based around just 7 basic commands: Migrate, Clean, Info, Validate, Undo, Baseline and Repair.

Does Flyway support multiple databases?

During development you need a fast, automated way to build multiple copies of a database on any development or test server, with each database at the right version.

Are Flyway migrations transactional?

Flyway and Transactions. With Flyway, if you make a mistake and an error is triggered, then the migration rolls back. Migrations are applied within a transaction whenever possible, and Flyway rolls back the migration if it receives an error message on its connection.


1 Answers

Providing this property solves the problem partially: flyway.schemas=FLYWAY,PUBLIC.

By doing so, the history table will be stored in the schema FLYWAY but all the migrations will be run by default on this schema.

Please refer to http://flywaydb.org/documentation/commandline/migrate.html and look for schemas for more details.

I found 2 issues to this approach, which can be fixed with minor tweaks.

1st issue:

The schema FLYWAY must be existing before any Flyway migration attempt. This can be done in java by using stmt.execute("CREATE SCHEMA IF NOT EXISTS FLYWAY"); and close the database before migration

2nd issue:

All the migrations will run by default on the schema FLYWAY. This can be fixed by modifying each SQL migration file to specifically point to PUBLIC schema. Each file would then contain these statements: create table PUBLIC.PERSON (...);

I've solved my problem at hand, but I'm not fully happy with the fix and the extra manual work. Hopefully someone can come with a better answer (more native way) and less tweaks.

like image 64
Christian MICHON Avatar answered Nov 14 '22 17:11

Christian MICHON