Product articles Deployment checks and safeguards

Find the Version of a Flyway-managed Database

Maintaining a version of a database opens a lot of possibilities, especially if an automated process can easily grab the current version, at runtime. 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. The article describes various ways to get the current Flyway schema version from Flyway, and how to get it using SQL, in SQL Server, MySQL, PostgreSQL and SQLite. Read more

Passing Parameters and Settings to Flyway Scripts

This article explains the various ways of using placeholders to pass information and settings to any Flyway script, to gain bit of extra flexibility in a migration run., providing examples of conditional execution, running SQL expressions using environment variables and even one of using placeholders in a callback to send a warning notification to your phone, after a migration completes. Read more

Running Flyway Pre-Migration Checks on the Database

This article demonstrates how to run a preliminary check that issues a warning, or throws an error, if the conditions aren't met for a Flyway migration to succeed. It provides some example checks for PostgreSQL databases that use Flyway SQL callbacks to ensure the server is running the correct PostgreSQL version, or that the database has a required extension installed. 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