vikunja-api/docs/content/doc/development/db-migrations.md
konrad 9e39399689 Migration (#120)
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
2020-01-19 16:52:16 +00:00

1.9 KiB

date title draft type menu
2019-03-29:00:00+02:00 Database migrations false doc
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 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.