Migration Scripts

To learn more about migration scripts including versioned migration scripts, repeatable migration scripts, undo migration scripts, and the order of execution for migration scripts, please see our page about Migration scripts.

Schema model tab

With Flyway Desktop it is possible to capture database changes into a model on the Schema model tab.  This captures the CREATE DDL for each object.  Committing this into version control provides an object-level history of how each object changes over time.  This can help identify conflicts if two team members are changing the same object and can also help with getting back to a previous version of an object (e.g. you can just run the previous version of a stored procedure with CREATE OR REPLACE). 

Schema model tab > Apply to database 

If you are on a dedicated development database, you should visit the Version Control tab to Pull the latest changes from the remote repository to your local repository.   On the Schema Model tab, switch to Apply and then you can apply those changes to your development database.  This will get the latest state of the objects onto your development database. 

Apply to database may also be used when switching branches.

Generate migrations tab

On the Generate migrations tab, you'll be able to see changes that have been made to your schema model that have not yet been captured in migration scripts. You can select the changes that you want to import into a new migration script. 

Migrations tab

The Migrations tab will show you all the migration scripts in your project.  If you configure/select a target database, you can see which scripts were executed against that target, when, and how long they took.  You can also see any pending migration scripts that need to run on that environment.  

You can also execute the flyway commands from this tab. 

Development database

A development database is linked to a project for the purpose of capturing change into the schema model. Flyway Desktop enables a connected development experience.  You can make changes directly to your development database, and then when you're ready to commit these to your version control system, use the Schema model tab to script these to your project. When you are ready to deploy these changes to a downstream environment you can generate migration scripts using the Generate migrations tab. 

Shadow database

The shadow database is a separate database that is needed in development for generating migration scripts.  When you generate migrations with Flyway Desktop, we run the migration scripts in the project against the shadow database.  Then, we use our schema comparison technology to compare the schema model to the shadow database.  This allows us to show you what changes have been made to your schema model that have not been captured in migration scripts yet.  

See Shadow Database or Shadow Schema for more details.

Baselining

When working with an existing database, you must setup a baseline that represents the current state of your production database.  This is necessary so that we can build the shadow database from scratch when you generate migrations to understand any new changes on your development database that haven't been imported into the project yet.  This is also important so you can spin up new environments in dev and test or deploy to new client sites.  Learn more about how to setup a baseline.