9e39399689
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
71 lines
No EOL
1.9 KiB
Markdown
71 lines
No EOL
1.9 KiB
Markdown
---
|
|
date: "2019-03-29:00:00+02:00"
|
|
title: "Database migrations"
|
|
draft: false
|
|
type: "doc"
|
|
menu:
|
|
sidebar:
|
|
parent: "development"
|
|
---
|
|
|
|
# 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](https://github.com/techknowlogick/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. |