Комментарии 7
Поэтому, лучше всего в качестве префикса использовать временную метку: создать миграции с одинаковой меткой секунда в секунду меткой маловероятно.
Маловероятно, но возможно.
<душнила>
Ради интереса попробую вспомнить теорвер: если считать создание миграции независимым событием, то вероятность создать миграцию в определённую секунду рабочего дня равна 1/8*60 (8 часовой рабочий день, 60 секунд в 1 часу).
Тогда вероятность создать две миграции двумя независимыми программистами в одну секунду будет 1/480 * 1/480 = 1/19200.
</душнила>
Я для себя решил, использовать отдельный специализированный софт для миграций по типу Flyway и Liquibase независимо от языка программирования проекта. Так можно унифицировать CI/CD и не искать отдельные решения для разных языков. Хотя в последнее время golang-migrate мне импонирует, так как он написан не на Java ))
У .sql миграций есть одна редкая, но критичная проблема - они не позволяют менять СУБД. Столкнулись с ней, когда в гос. секторе все начали переходить с Sql Server на Postgre. В нашем случае (.NET стек) миграции сохранить не удалось, интересно, есть ли инструменты, которые поддерживают миграции разных СУБД бесшовно?
Спасибо за статью))) в последнее время вместо типа serial пишу GENERATED ALWAYS AS IDENTITY
Поддержка транзакций
Что-то я не смог прикрутить транзакции к гусю.
Пока так:
func runMigrations(ctx context.Context, db *sql.DB) error {
if err := goose.SetDialect("postgres"); err != nil {
return fmt.Errorf("failed to set dialect: %w", err)
}
if err := goose.UpContext(ctx, db, "postgres/.migrations"); err != nil {
return fmt.Errorf("failed to run migrations: %w", err)
}
return nil
}
func createTables(ctx context.Context, p *pgxpool.Pool) error {
db := stdlib.OpenDBFromPool(p)
defer db.Close()
if err := runMigrations(ctx, db); err != nil {
return err
}
return nil
}
В поиске оптимального подхода к миграциям в Go