github.com/rubenv/sql-migrate (go): SQL Schema migration tool for Go.  Key features:  To install the library and command line program, use the following:  The main command is called sql-migrate.  Each command requires a configuration file (which defaults to dbconfig.yml, but can be specified with the -config flag). This config file should specify one or more environments:  The `table` setting is optional and will default to `gorp_migrations`.  The environment that will be used can be specified with the -env flag (defaults to development).  Use the --help flag in combination with any of the commands to get an overview of its usage:  The up command applies all available migrations. By contrast, down will only apply one migration by default. This behavior can be changed for both by using the -limit parameter.  The redo command will unapply the last migration and reapply it. This is useful during development, when you're writing migrations.  Use the status command to see the state of the applied migrations:  If you are using MySQL, you must append ?parseTime=true to the datasource configuration. For example:  See https://github.com/go-sql-driver/mysql#parsetime for more information.  Import sql-migrate into your application:  Set up a source of migrations, this can be from memory, from a set of files or from bindata (more on that later):  Then use the Exec function to upgrade your database:  Note that n can be greater than 0 even if there is an error: any migration that succeeded will remain applied even if a later one fails.  The full set of capabilities can be found in the API docs below.  Migrations are defined in SQL files, which contain a set of SQL statements. Special comments are used to distinguish up and down migrations.  You can put multiple statements in each block, as long as you end them with a semicolon (;).  If you have complex statements which contain semicolons, use StatementBegin and StatementEnd to indicate boundaries:  The order in which migrations are applied is defined through the filename: sql-migrate will sort migrations based on their name. It's recommended to use an increasing version number or a timestamp as the first part of the filename.  Normally each migration is run within a transaction in order to guarantee that it is fully atomic. However some SQL commands (for example creating an index concurrently in PostgreSQL) cannot be executed inside a transaction. In order to execute such a command in a migration, the migration can be run using the notransaction option:  If you like your Go applications self-contained (that is: a single binary): use packr (https://github.com/gobuffalo/packr) to embed the migration files.  Just write your migration files as usual, as a set of SQL files in a folder.  Use the PackrMigrationSource in your application to find the migrations:  If you already have a box and would like to use a subdirectory:  As an alternative, but slightly less maintained, you can use bindata (https://github.com/shuLhan/go-bindata) to embed the migration files.  Just write your migration files as usual, as a set of SQL files in a folder.  Then use bindata to generate a .go file with the migrations embedded:  The resulting bindata.go file will contain your migrations. Remember to regenerate your bindata.go file whenever you add/modify a migration (go generate will help here, once it arrives).  Use the AssetMigrationSource in your application to find the migrations:  Both Asset and AssetDir are functions provided by bindata.  Then proceed as usual.  Adding a new migration source means implementing MigrationSource.  The resulting slice of migrations will be executed in the given order, so it should usually be sorted by the Id field.
Keywords: bindata|go|sql|sql-schema-migration