Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Migrations table creation and insert fails on MySQL during transaction #822

Open
JuozasVainauskas opened this issue Sep 9, 2024 · 2 comments

Comments

@JuozasVainauskas
Copy link
Contributor

JuozasVainauskas commented Sep 9, 2024

MySQL does not support transactions on CREATE operation:

goose/migrate.go

Lines 249 to 263 in 1984573

func createVersionTable(ctx context.Context, db *sql.DB) error {
txn, err := db.BeginTx(ctx, nil)
if err != nil {
return err
}
if err := store.CreateVersionTable(ctx, txn, TableName()); err != nil {
_ = txn.Rollback()
return err
}
if err := store.InsertVersion(ctx, txn, TableName(), 0); err != nil {
_ = txn.Rollback()
return err
}
return txn.Commit()
}
part fails because transactions are used. When this code is invoked, the table is created successfully but insert fails and we get the state where we have empty goose_db_version table since transaction does not rollback table creation. Later, following migrations fail with error:

2024/09/09 13:01:19 database migration failed: no next version found

Would it be possible to run createVersionTable function without transaction for MySQL dialect? This solution would work and fix our problem. I could implement this but need some guidance and ideas how I could code it up.

@JuozasVainauskas JuozasVainauskas changed the title Migrations table creation and insert fails on MySQL with gh-ost DDL strategy Migrations table creation and insert fails on MySQL during transaction Sep 9, 2024
@mfridman
Copy link
Collaborator

mfridman commented Sep 12, 2024

I'll need to investigate this a bit further, but I'm quite surprised as we test goose against a number of databases and afaik many users use MySQL or MariaDB already.

@jrozner
Copy link

jrozner commented Dec 6, 2024

We recently ran into this problem as well. Wondering if there are any possible solutions short of taking these limitations into account as we write further migrations (eg. each atomic statement gets it's own migration)?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants