Simple DB migration CLI based on http://github.com/mattes/migrate
This installation assume
$ go get -u -d github.com/trimeego/mg
$ go build -tags 'mssql' -o /usr/local/bin/mgsql github.com/trimeego/mg
$ go build -tags 'postgres' -o /usr/local/bin/mgpostgres github.com/trimeego/mg
mg can create proper migration files. In order to create a migration file, you supply the intent behind the script in snake case, such as create_user_table.
$ mg create create_user_table
This will create timestamped .up.sql and .down.sql files.
For convenience, you can place a .mg.yaml file in the migration folder with the env options that you want to make available. This is strongly recommended to avoid mistakes.
Adding the following .mg.yaml allows provides dev, qa, and prod env options:
dev: postgres://icgadmin:password@localhost:5432/vantage
qa: postgres://icgadmin:password@test-postgres.caxctts3oq6h.us-west-2.rds.amazonaws.com:5432/vantage
prod: postgres://icgadmin:password@prod-postgres.ctuifd37tvce.us-west-2.rds.amazonaws.com:5432/vantage
These can be used anywhere using the --env flag. Given this config file, the following two commands are equivalent.
$ mg version --url postgres://icgadmin:password@localhost:5432/vantage
$ mg version --env dev
To get the current version:
$ mg version --env dev
To migrate up to the current level.
$ mg up --env dev
To migrate up a specific number of steps from the current version:
$ mg up 3 --env dev
To migrate down a specific number of steps from the current version:
$ mg down 3 --env dev
To migrate to a specific version from the current version:
$ mg goto 1479382989 --env dev
In some cases, particularly during development, one must force the current level to a particular level. This is particularly true when a new script fails to do a syntax error. In this case, you will need to force the migration to think that it is at a specific version.
To migrate down a specific number of steps from the current version:
$ mg force 1478293889 --env dev