Clever Geek Handbook

Migration options across multiple directories

If I want to organize my migrations in multiple directories (let's say I am using SQL migrations and in the "sql" directory I have a "main" directory and then a "special" directory).

So, under sql / main I have "V1.1__some_change" etc.

Then I want to add other migrations to sql / special as well. But migration version numbers must be different in all directories, for example, I could not put "V1.1__some_other_change" in sql / special, as it would cause a conflict.

But it is not easy to manage linear version numbers in many different directories. Is there a good approach for solving this problem?

Hope this question is clear.

+3


source to share


2 answers


Well, it all depends on why special is "special" and how it relates to "main" .

If they have the same lifecycle , you can use a different numbering scheme (integer mostly, point releases in ad hoc), or keep track of the assigned migration number on a share (board, wiki page, ...) so it's easy to find out. which of the following is available.



If they have separate lifecycles , you can have separate Flyway instances tracking them (each with a different flyway.table).

+3


source


I faced the same problem today. I have updated Flyway 1.7 to the latest version 2.0.3. And I noticed that migrations no longer work like in 1.7.

We use different subfolders of the base folder (db.migrations) to store migrations for different database schemas that have separate lifecycles with their own schema_version tables:

src->main->resources->db.migrations
 ->business_partitions
     -> V1_1__BUSINESS_PARTITION_INDEXES.sql
     -> V1__BUSINESS_PARTITIOS.sql
 ->tech
     -> V1_1__TECH_CERTIFICATES_AND_DECRYPTORS_TABLES.sql
     -> V1__TECH.sql
     -> V2__JMS.sql
 ->view
     -> V1__PARTITION11_DB_CREATION_SCRIPT_VIEWS.sql

When we did our db migrations today using the following lines in Java:

Flyway flyway = new Flyway();
flyway.setDataSource(dataSource);
flyway.setLocations("db.migrations.business_partitions");
flyway.migrate();

no migrations have been performed.



I dug into the source code of the flyover a bit and found that the problem was that the location was being filtered in the mergeLocations () method of the CompositeMigrationResolver class.

There my location was filtered as business_partitions is a subfolder of db.migrations which is the default for BaseDir and BasePackage.

I worked by setting BaseDir and BasePackage explicitly:

flyway.setBaseDir("db.migrations.business_partitions");
flyway.setBasePackage("db.migrations.business_partitions");

I read that these two methods will be deprecated in span 3, so maybe this will fix our problem as well.

+2


source






More articles:


All Articles