Managing patches subsets with Flyway

Question

I have one application using a single database schema. Nonetheless, the application has a core (having its DB objects) and can be extended with a plugin logic (each plugin having its DB objects). Core DB objects and Plugins DB objects are distinct sets, since plugins are optional and may exist or may not.

Thus I need separate versionig and migration control for Core and each single plugin.

I'm wondering if there is some way, using Flyway, to manage this separate "migration paths".

The only thing I can think about is creating, under the same, single DB schema hosting the application, many different Flyway metadata tables (like schema_version_core, schema_version_plugin1, etc.) and managing migrations of each component independently.

Is this doable? Any smarter suggestion?

Many thanks

Answer 1

I highly recommend you split your DB into schemas, as this is really what they are for: managing sets of objects.

If that is not an option, the alternative you suggested works fine. Just be careful when invoking clean, as it will then clean the entire schema not just the part for one of your plugins.

Answer 2

I am currently struggling with the same problem: An application which is made of several "base" components which all could have their own database objects.

I tried the option to put all in the same schema and using different flyway meta tables, but this does not work: When flyway comes to process e.g. the second table for the second module and discovers that the schema is not empty (because the first module has migrated its db changes), it stops, as flyway has now no chance to determine the state of the db and its migrations.

Also using base line versions do not help, as in that case the changes of the base line would be skiped for the next modules... I think the only reasonable solution with flyway would be to use different schemas....