Go mod tidy [skip ci] Add modules/migration to docs [skip ci] update date fmt Merge branch 'master' into feature/migration # Conflicts: # pkg/routes/api/v1/info.go Add docs on how to create a migrator Add available migrators to /info endpoint Return a message once everything was migrated successfully Add swagger docs for wunderlist migration Docs for migration [skip ci] Fix due date fixture in migration test Fix staticcheck Fix lint Logging and cleanup Make the migrator work with real data Add routes for migration Fix misspell Add method to store a full vikunja structure into vikunja Add getting all data from wunderlist Add attachment migration from wunderlist Add done and done at to wunderlist migrator Add todo Add wunderlist auth url implementation Fix lint Finish wunderlist migration Added all structs for the wunderlist migratior Fix owner field being null for user shared namespaces (#119) Update copyright year (#118) Add option to disable registration (#117) Added migrator interface Co-authored-by: kolaente <k@knt.li> Reviewed-on: https://kolaente.dev/vikunja/api/pulls/120
1.9 KiB
date | title | draft | type | menu | ||||
---|---|---|---|---|---|---|---|---|
2019-03-29:00:00+02:00 | Database migrations | false | doc |
|
Database Migrations
Vikunja runs all database migrations automatically on each start if needed.
Additionally, they can also be run directly by using the migrate
command.
We use xormigrate to handle migrations, which is based on gormigrate.
Add a new migration
All migrations are stored in pkg/migrations
and files should have the same name as their id.
Each migration should have a function to apply and roll it back, as well as a numeric id (the datetime) and a more in-depth description of what the migration actually does.
To easily get a new id, run the following on any unix system:
{{< highlight bash >}} date +%Y%m%d%H%M%S {{< /highlight >}}
New migrations should be added via the init()
function to the migrations
variable.
All migrations are sorted before being executed, since init()
does not guarantee the order.
When you're adding a new struct, you also need to add it to the models.GetTables()
function
to ensure it will be created on new installations.
Example
{{< highlight golang >}} package migration
import ( "github.com/go-xorm/xorm" "src.techknowlogick.com/xormigrate" )
// Used for rollback
type teamMembersMigration20190328074430 struct {
Updated int64 xorm:"updated"
}
func (teamMembersMigration20190328074430) TableName() string { return "team_members" }
func init() { migrations = append(migrations, &xormigrate.Migration{ ID: "20190328074430", Description: "Remove updated from team_members", Migrate: func(tx *xorm.Engine) error { return dropTableColum(tx, "team_members", "updated") }, Rollback: func(tx *xorm.Engine) error { return tx.Sync2(teamMembersMigration20190328074430{}) }, }) } {{< /highlight >}}
You should always copy the changed parts of the struct you're changing when adding migraitons.