status-im
/
migrate
mirror of https://github.com/status-im/migrate.git
2
0
Fork 0
Code Issues Projects Releases Wiki Activity
Database migrations. CLI and Golang library.
155 Commits 5 Branches 25 Tags 1.2 MiB
Go 98.6%
Makefile 1%
Dockerfile 0.3%
Go to file
David Campbell 9694775972 prefix migration files with epoch 
Using epoch prefixed filenames, multiple developers can commit
migrations while minimizing versioning conflicts.

This commit remains backwards compatible with all previous migrations
and requires no changes to the `schema_migrations` table.

This commit also cleans up migrate-test temp directories
 		2015-12-20 16:18:25 -08:00
driver Move the registry to driver package 2015-10-22 16:29:26 -04:00
file Add some docstring explanation to makeFiles 2015-09-14 16:41:19 -07:00
migrate prefix migration files with epoch 2015-12-20 16:18:25 -08:00
pipe refactor cli 2014-08-14 00:22:56 +02:00
.gitignore exclude test sqlite3 db 2015-09-15 23:08:11 +01:00
.travis.yml Dropping support for go 1.3 2015-10-22 19:29:14 -04:00
Dockerfile Fix test with optionated drivers 2015-10-15 12:49:43 -04:00
LICENSE improve comments and add license 2014-08-13 03:37:48 +02:00
Makefile Don't trust travis go 2015-10-15 14:18:23 -04:00
README.md Error in example mysql driver import statement 2015-11-13 11:57:52 +00:00
docker-compose.yml remove leftover 2015-10-15 14:19:14 -04:00
main.go Import drivers in CLI 2015-11-12 11:38:53 +01:00
version.go update to version 1.2.0 2014-10-11 01:39:08 +02:00

README.md

migrate

Build Status GoDoc

A migration helper written in Go. Use it in your existing Golang code or run commands via the CLI.

GoCode   import github.com/mattes/migrate/migrate
CLI      go get -u github.com/mattes/migrate

Features

  • Super easy to implement Driver interface.
  • Gracefully quit running migrations on ^C.
  • No magic search paths routines, no hard-coded config files.
  • CLI is build on top of the migrate package.

Available Drivers

Need another driver? Just implement the Driver interface and open a PR.

Usage from Terminal

# install
go get github.com/mattes/migrate

# create new migration file in path
migrate -url driver://url -path ./migrations create migration_file_xyz

# apply all available migrations
migrate -url driver://url -path ./migrations up

# roll back all migrations
migrate -url driver://url -path ./migrations down

# roll back the most recently applied migration, then run it again.
migrate -url driver://url -path ./migrations redo

# run down and then up command
migrate -url driver://url -path ./migrations reset

# show the current migration version
migrate -url driver://url -path ./migrations version

# apply the next n migrations
migrate -url driver://url -path ./migrations migrate +1
migrate -url driver://url -path ./migrations migrate +2
migrate -url driver://url -path ./migrations migrate +n

# roll back the previous n migrations
migrate -url driver://url -path ./migrations migrate -1
migrate -url driver://url -path ./migrations migrate -2
migrate -url driver://url -path ./migrations migrate -n

# go to specific migration
migrate -url driver://url -path ./migrations goto 1
migrate -url driver://url -path ./migrations goto 10
migrate -url driver://url -path ./migrations goto v

Usage in Go

See GoDoc here: http://godoc.org/github.com/mattes/migrate/migrate

import "github.com/mattes/migrate/migrate"

// Import any required drivers so that they are registered and available
import _ "github.com/mattes/migrate/driver/mysql"

// use synchronous versions of migration functions ...
allErrors, ok := migrate.UpSync("driver://url", "./path")
if !ok {
  fmt.Println("Oh no ...")
  // do sth with allErrors slice
}

// use the asynchronous version of migration functions ...
pipe := migrate.NewPipe()
go migrate.Up(pipe, "driver://url", "./path")
// pipe is basically just a channel
// write your own channel listener. see writePipe() in main.go as an example.

Migration files

The format of migration files looks like this:

001_initial_plan_to_do_sth.up.sql     # up migration instructions
001_initial_plan_to_do_sth.down.sql   # down migration instructions
002_xxx.up.sql
002_xxx.down.sql
...

Why two files? This way you could still do sth like psql -f ./db/migrations/001_initial_plan_to_do_sth.up.sql and there is no need for any custom markup language to divide up and down migrations. Please note that the filename extension depends on the driver.

Alternatives