search

golang-migrate / migrate

Database migrations. CLI and Golang library.
Other
15.36k stars 1.4k forks source link

Migrations that begin with the year 2024 fail during the 'up' migration process #1024

Open alazarbeyenenew2 opened 10 months ago

alazarbeyenenew2 commented 10 months ago

Describe the Bug Migrations that begin with the year 2024 fail during the 'up' migration process.

Steps to Reproduce

  1. run migration create migrate create -ext sql -dir internal/constant/query/schemas -tz "UTC"_sql_name
  2. run migrate up 3

Expected Behavior

`User panic: suint(-2077783112) expects input >= 0

goroutine 54 [running]: github.com/golang-migrate/migrate/v4.suint(...) github.com/golang-migrate/migrate/v4/util.go:45 github.com/golang-migrate/migrate/v4.(Migrate).readUp(0xd1e9d40, 0xffffffff, 0xffffffff, 0xd294340) github.com/golang-migrate/migrate/v4/migrate.go:582 +0x6be created by github.com/golang-migrate/migrate/v4.(Migrate).Up in goroutine 1 github.com/golang-migrate/migrate/v4/migrate.go:283 +0xea make: [Makefile:4: migrate-up] Error 2 (ignored)`

Migrate Version e.g. v3.4.15, v3.4.17

Loaded Source Drivers e.g. s3, github, go-bindata, gcs, file Obtained by running: migrate -help

Loaded Database Drivers e.g. postgresql

Stacktrace

`User panic: suint(-2077783112) expects input >= 0

goroutine 54 [running]: github.com/golang-migrate/migrate/v4.suint(...) github.com/golang-migrate/migrate/v4/util.go:45 github.com/golang-migrate/migrate/v4.(Migrate).readUp(0xd1e9d40, 0xffffffff, 0xffffffff, 0xd294340) github.com/golang-migrate/migrate/v4/migrate.go:582 +0x6be created by github.com/golang-migrate/migrate/v4.(Migrate).Up in goroutine 1 github.com/golang-migrate/migrate/v4/migrate.go:283 +0xea make: [Makefile:4: migrate-up] Error 2 (ignored)`

edsonjuniordev commented 9 months ago

I have the same problem

alazarbeyenenew2 commented 9 months ago

I solved the problem by manually changing the year to 2023

dhui commented 9 months ago

suint(-2077783112) looks like an overflow. Are you on a 32-bit system? See also:

edsonjuniordev commented 9 months ago

I'm using a 64-bit system. And the problem started to occur in 2024.

alazarbeyenenew2 commented 9 months ago

i am on 64-bit but this is this is started 2024 this is how i identify the problem then try to solve in my way

oitan commented 9 months ago

y2k never ended

mateusfmello commented 6 months ago

I'm having the same problem.

I believe the quickest solution to this would be to migrate away from timestamps and use the sequential option.

However, I see that it is a complex thing to do because in addition to having to change all the migration files, you also have to update the database.

Looking at the database I have, the schema_migrations table only has one version line, but it is a version code that does not exist in my migrations. I think it might be the time stamp of the last run, but I'm not sure and I don't see much point in it. In Doctrine, which I am more accustomed to using, as I am migrating from PHP to GoLang, it stores all executed migrations, that is, each migration after being executed becomes a row in the schema_migrations table.

If someone can guide me on how Migrate works with the schema_migrations table, I can write a script to facilitate the migration of the timestamp to 6-digit sequential order, which is the default for migrate create -seq.