This article demonstrates using PowerShell-based tokenization to compare two SQL migration files. It ignores non-functional changes like comments or formatting and pinpoints the first meaningful change in SQL logic, providing detailed feedback on its location and nature. Read more
This article provides a scripted SQL tokenizer script that quickly verifies whether a Flyway validation error is a real cause for concern, due to retrospective metadata changes, or just the result of a developer valiantly adding formatting and documentation to improve the code. If the changes are purely cosmetic, we can safely run Flyway repair to resume normal migrations. Read more
If you can convert a SQL file to HTML, then you can inspect your Flyway migration files in a browser. This is especially useful if your SQL is color-coded with the same conventions as it was in your IDE. It is even better still if your browser can allow you to scan through many files, moving from file to file with a single click. This article demonstrates how to do this with a few PowerShell scripts. Read more
Database models have all sorts of useful applications during Flyway development to help us automate those repetitive development tasks that otherwise slow down delivery. This article shows how models can help us automate mundane tasks such as generating a build script for any version of a database or deleting the data from every table. Read more
A database model is a standard document that represents the logical design and structure of a database. If we save a model each time Flyway creates a new version of the database, then we can find out what's in each version, and get an overview of how that structure changed between any two versions. This has all sorts of uses in team-based database development work. Read more
This article demonstrates a cross-RDBMS way of searching through a set of SQL migration files, in the right order, to get a narrative summary of what changes were made, or will be made, to one or more of the tables or routines within each migration file. Getting these summary reports, even from a set of SQL migrations, isn't difficult, but having a few examples makes it a lot quicker to get started. Read more
Armed with a schema comparison engine and an object-level directory of the source for every recent version of the database, you'll be able to remove a lot of the uncertainty around merging database changes back into development. Read more
As a database gets larger, and development more complex, so it becomes increasingly necessary to be able to search for strings in the source files and the database itself. Maybe you need to find when a table first got created, when a foreign key was added, or to find out which tables lack documentation. I'll show you how to answer these sorts of questions by running simple 'wildcard' searches on your Flyway migration files, or source files, as well as more targeted searches on certain parts of your database model. Read more
If you save a metadata 'model' for every new version of a database created by Flyway, you can compare the current model to the previous one to see what changed. In turn, you can then generate a database E-R diagram that highlights the changed objects, instantly making those changes visible to other team members. Read more
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
If you can generate a file-based (JSON) model for each new version of a database, produced by a Flyway migration, then you have an easy way to run simple reports to help you search, list, and understand the structure of these databases. I'll show how to produce the models using PowerShell and then run some queries against them to generate the reports. Read more
Flyway provides a database-independent way for a team to track, manage and apply database changes, while maintaining strict control of database versions. It updates a database by running a series of versioned migration scripts, in order, and keeps track of all the changes in a special "schema history" table. It sounds simple, but it is easy to derail this team discipline if you don't find the right answers to the following questions… Read more
The payback of DevOps is not simply in automation but in using that automation to increase the visibility of the development processes. This article demonstrates way to make Flyway developments more visible, regardless of your RDBMS, such as by providing a detailed migration history, and change reports that reveal detail of what is going on to all involved. Read more
This article demos a novel way to report on the progress of your Flyway development project. It provides both SQL and PowerShell versions of code that extracts information for each database version from the Flyway schema history table and then plots it in a Gantt chart. Read more
A set of PowerShell cmdlets that will 'diff' two versions of a database and provide a high-level overview of the major database changes made by successive Flyway migrations. You can 'diff' a SQL Server database to the same one on PostgreSQL and find out which objects are the same and which are different. Read more
How to send Flyway logging and error output to JSON and consume it in PowerShell to produce ad-hoc database migrations reports, including any errors that occurred, the version of the database, runtimes for each migration script and more. Read more