What’s Included?
The MyBatis Migrations package is small and simple. The following is the contents of the unzipped
package:
./lib/mybatis-3-core-3.0.0.188.jar
./migrate
.migrate.cmd
The single MyBatis JAR file is the only dependency that MyBatis Migrations has. The two script files do
the same thing, but as you can see, one is for *nix shells and the other is for Windows (Note: cygwin
users should still call the .cmd version).
The ‘migrate’ Command
The entire Migrations system can be accessed through this one simple command. You can access the
built-in help by typing: migrate --help
Calling the migrate command with no options or invalid options also produces the help message. Here’s
the output of the help command:
Usage: migrate command [parameter] [--path=<directory>] [--env=<environment>]
[--template=<path to template>]
--path=<directory> Path to repository. Default current working directory.
--env=<environment> Environment to configure. Default environment is 'development'.
--force Forces script to continue even if SQL errors are encountered.
--help Displays this usage message.
--trace Shows additional error details (if any).
--template (Optional) Specify template to be used with ‘new’command
Commands:
init Creates (if necessary) and initializes a migration path.
bootstrap Runs the bootstrap SQL script (see scripts/bootstrap.sql for more).
new <description> Creates a new migration with the provided description.
up Run all unapplied migrations.
down Undoes the last migration applied to the database.
version <version> Migrates the database up or down to the specified version.
pending Force executes pending migrations out of order (not recommended).
status Prints the changelog from the database if the changelog table exists.
script <v1> <v2> Generates a delta migration script from version v1 to v2 (undo if v1 > v2).
We’ll go through each of these commands in detail, but first, let’s talk about lifecycle.
The MyBatis Migrations Lifecycle
Database change management is difficult at the best of times, so to make the situation better, it’s
important to have a good database evolution strategy. That employed by MyBatis Migrations targets a
few key goals:
• Consistent – The schema should be predictable on every machine it’s created on.
• Repeatable – The schema can be destroyed and recreated a predictable way.