The 'bootstrap' command

If you’re working from an existing database, you need to start from a known state. There’s no point in trying to rewind time and shoehorn your existing database into a series of migration scripts. It’s more practical to just accept the current state of your database schema and identify this as the starting point. The bootstrap script and command exist for this reason.

In the scripts directory you’ll find bootstrap.sql. You can put your existing DDLscript in this file. If you don’t have a DDL script, you can export your existing database schema and put it in the bootstrap file. You’ll want to clean it up so that it doesn’t contain anything specific to any one environment, but otherwise almost any script should work. Watch out for DDL that contains conditional elements or branching logic that could generate multiple schemas. While this is sometimes necessary, it’s a really good idea to try to eliminate this aspect of your database schema (put such conditional and branching logic in your code or stored procedures instead). If you have multiple DDL files, you’ll have to merge them into the single bootstrap file.

But worry not, it’s the last time you’ll ever modify it. One of the rules above was immutable change scripts... the bootstrap is included in that rule.

Note The bootstrap.sql is a plain text file and is not a valid “migration” that you’ll learn about later. It’s meant to be similar to the scripts you probably already use. Therefore you cannot rollback the bootstrap file, nor is it tracked in the audit logs... without exception, whatever you put in the bootstrap file cannot leverage the benefits of the other migration commands. But we have to start somewhere, and it’s best to look forward.

To run the bootstrap file, you simply call the bootstrap command. You do this once to initialize your database into a known working state. From then on, you’ll use migration scripts to evolve the database schema.

The bootstrap command has no parameters. So running it is as simple as:

/home/cbegin/testdb$ migrate bootstrap

As usual, you can use the --path option to specify the repository path, otherwise the current working directory is assumed to be the root of your migration repository (aka migration path).

If there are environment specific elements in your bootstrap script, you’ll learn later that you can use properties to deal with those.