-
-
Notifications
You must be signed in to change notification settings - Fork 3.9k
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
AutoMigrate creating different unique Index on subsequent runs #6378
Comments
What version of postgres are you using? This seems to be an error caused by the handling of the index name, but in fact I cannot reproduce the wrong creation of this index from the link you provided. |
using |
And yeah sorry with the given tests you can't actually create the wrong index because the tests insert conflicting data. But you should see errors that it is failing to create those indexes. I just included the "wrong" index in the description to show what |
refer to #6381 (comment) if DB.Migrator().HasIndex(&User{}, "users_description_key") {
DB.Exec(`ALTER TABLE ? DROP CONSTRAINT ?`,
clause.Expr{SQL: "users"},
clause.Expr{SQL: "users_description_key"},
)
} |
Yeah that is what I've been doing to fix it but gorm shouldn't be creating that index in the first place. Do we know why it gets created and can we get a fix the next release? |
GORM Playground Link
go-gorm/playground#608
Description
I have an existing database and consistently run
Automigrate
but after upgrading my gorm version from 1.28.3, the automigrate is creating different unique indexes than the ones I have defined and already exist in my database.To reproduce, pull this branch and run
GORM_DIALECT=postgres go test
. This should work and pass tests. But if you run it again, it will fail to make migrations because it is trying to create a uniqueIndex and uniqueConstraint that doesn't have the samename
orwhere
clause as the unique index that I defined:ERROR: could not create unique index "idx_users_description" (SQLSTATE 23505)
After the initial run of
AutoMigrate
the unique indexes that I defined are correctly created:But after the next time I run
AutoMigrate
, it created new unique indexes with a different name and without the where clause:I can only get to the state of the second picture if I don't have any data that conflicts the
where
clause of the unique index of thedescription
column. In my use case, I have a table with a unique index with awhere deleted_at is NULL
condition but now that myAutoMigrate
behaves differently, I cannot run migrations.Did something change with how
AutoMigrate
handles unique indexes?The text was updated successfully, but these errors were encountered: