search

golang-migrate / migrate

Database migrations. CLI and Golang library.
Other
15k stars 1.38k forks source link

DB driver operations should be atomic #151

Open dhui opened 5 years ago

dhui commented 5 years ago

Describe the Bug Not all DB driver operations are atomic as show by https://github.com/golang-migrate/migrate/pull/150

Operations that aren't locked:

Steps to Reproduce Creating multiple instances of a DB driver (which will attempt to create the schema/version table) See test added in this PR: https://github.com/golang-migrate/migrate/pull/150/files#diff-5cc52c39a5031732bc6d3821ffc558e6

Expected Behavior All DB driver operations should be atomic

Migrate Version N/A

Loaded Source Drivers N/A

Loaded Database Drivers N/A

Go Version N/A

Stacktrace N/A

Additional context The fix for all drivers might be complicated. Not all DB driver lock implementations are reentrant. Some DB drivers implement locks using other tables which complicates the fix. It may be cleaner to expose schema/version table operations in the new DB driver interface and provide guidance on lock implementations.

dhui commented 5 years ago

Schema version table creation is locked in Postgres after this PR: https://github.com/golang-migrate/migrate/pull/150 All other DBs will have their schema version table creation locked after this PR: https://github.com/golang-migrate/migrate/pull/173

Locking schema version table creation created a bug when dropping: https://github.com/golang-migrate/migrate/issues/164

173 fixes the "dropping bug" but does so by not re-creating the schema version table. This has the side-effect where after calling database.Driver.Drop(), you'll need to recreate your database.Driver instance using database.Driver.Open(). If you're using a migrate.Migrate instance, that'll also need to be re-created after calling migrate.Migrate.Drop() for the same reason.