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 always alters columns of "bigint" #123
Comments
(updated issue description with playground PR) |
I second this. I have the following:
The strange part is in my postgresql, ID in the allocationEntity created is BigInt not string, but in the vult, it is string. |
related to #111 |
@a631807682 Hey! Do you know when this issue will be resolved? |
I don't know, it is waiting for the maintainer review. |
No problem, i see that it fails on tests on some driver, that might be an issue? |
It will fix by go-gorm/gorm#5620 |
GORM Playground Link
go-gorm/playground#500
Description
The problem is rather simple: every run of AutoMigrate will execute a redundant ALTER COLUMN for int types (int64).
The reason?: The GORM Postgres driver uses "bigint" as the type for go's int64. However, in postgres, bigint is not the type name internally - it's just an alias to int8:
SELECT * FROM pg_type WHERE typname IN ('int8', 'bigint');
In practice, this means that AutoMigrate will always detect a discrepancy ("int8" != "bigint") and run an ALTER COLUMN.
The bad: You need to disable AutoMigrate by default to avoid these redundant queries.
The ugly: The ALTER COLUMN int8 to bigint actually breaks conditional indexes which depend on the column and requires VACUUM ANALYZE to fix (a Postgres issue, not a problem for here, I'll report when I have time). However, suffice to say, the redundant ALTER COLUMNs are not benign.
Happy to create a pull request.
The text was updated successfully, but these errors were encountered: