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

Connecting Easily to Data Containers from Database Tools and IDEs

Data containers can be created, destroyed and reset remarkably quickly, making them very effective for test-driven database development. Each time we reset a data container, it will have the same host, but both the port and password will be different. This article demonstrates how we can use simple PowerShell automation to smooth the process of dealing with ephemeral connection details in our IDEs and command line tasks. Read more

Using TOML Configuration Files with Flyway

This article discusses Flyway's transition from CONF to TOML configuration files. It highlights the advantages of TOML, such as improved readability, flexibility in managing complex database configurations, and support for specifying multiple database environments. It also discusses a few of the differences to be aware of when switching existing Flyway projects to the new config system. Read more

Using Bash with Flyway

If you're using a Linux-based operating system, Bash is the obvious choice of scripting language for Flyway. This article demos the basics of dealing with credentials in team-based database development, when using 'traditional' flyway.conf files, and how to save and parse the JSON output of Flyway commands, for example to retrieve the current schema version. It provides a full automation example that will allow a team to maintain several copies of a database, one per development branch, from a Flyway project. Read more

Running Database Tasks and Tests on Clones in Redgate Test Data Manager

This article demonstrates how to adapt your current database development and testing regimes to use clones (data containers) in Redgate Test Data Manager. It demonstrates how to handle dynamic connection details and how to get from the containers the connection and database information that your development tasks and tests need to function correctly. Read more

Provisioning Clones for Flyway Projects

This article demonstrates how to use Redgate Test Data Manager to automate the delivery and teardown of data containers (clones) on four different RDBMS platforms, SQL Server, PostgreSQL, Oracle and MySQL, for use in Flyway development projects. Read more

Getting Started with Cloning in Redgate Test Data Manager

This article takes a 'first look' at database cloning in Redgate Test Data Manager, explaining what it does and its advantages in team-based, test-driven database development. It will get you set up with the cloning CLI and then demos the basics of defining and creating images, and then creating and destroying database containers (clones) using PowerShell. Read more

Flyway’s Validate Command Explained Simply

The Validate command aims to ensure that Flyway can reliably reproduce an existing version of a database from the source migration scripts by warning you if files are retrospectively added, removed or altered that would prevent it from doing so. Validation errors are Flyway's warning that "the source for this version has changed". Read more

Flyway’s Clean Command Explained Simply

The Clean command resets a database to its initial state, before any Flyway migrations were applied. In other words, it empties the database. This can be useful for any development task that requires that you recreate the database structure, or for tearing down a test harness. It also allows you to try out experiments and alternative strategies within an isolated feature branch, and then reverse out of them. Read more

Flyway’s Baseline Migrations Explained Simply

A Flyway Baseline migration script is a single script with a B prefix that will migrate an empty database, or one that Flyway has 'cleaned', to the version specified in the file name. It is useful both for consolidating a long, often complex chain of historical migrations, and for capturing the current production version of a database, as the starting point for developing subsequent migrations. Read more

Redgate Test Data Manager

Redgate Flyway

Redgate Monitor

Overview

Protect

Automate

Monitor

Product articles