Finding the Version of a Flyway-managed Database Using SQL

Maintaining a version of a database opens a lot of possibilities, especially if an automated process can easily grab the current version, at runtime, using just SQL. You might, for example, have a routine that is only appropriate after a particular version. It is also very handy to be able to associate entries in an event log or bug report with the database version. No more desultory quests, when dealing with support issues, or when bug fixing, to find which database version was running when the bug happened. Read more

Cross-RDBMS Version Checks in Flyway

How does one check that a database is definitively at the version that Flyway says it is? Or that a test teardown procedure leaves no trace in the database? Or verify that an undo script returns a database's metadata to that state it should be in for the version to which you're rolling back? This article shows how to do high-level version checks, by comparing JSON models. Read more

Flyway Database Drift and How it Happens

Flyway's approach to database migrations is based on strict versioning, but there is a limit to what a single process can do to prevent 'drift'. This article explains how drift can happen, and why you also need source control and external processes that log changes, to prevent it. Read more

Creating Idempotent DDL Scripts for Database Migrations

How to write idempotent DDL scripts that Flyway can run several times on a database, such as after a hotfix has already been applied directly to the production database, without causing errors. Read more

Detecting Database Drift during Flyway Database Development

How to detect database drift prior to running a database migration, so that you can be certain that a database hasn't been subject to any 'uncontrolled' changes that could affect the migration or result in untested changes being deployed to production. Read more