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

Use the pg_type table to get valid type sizes for numeric types #61

Merged
merged 1 commit into from
Sep 28, 2021

Conversation

chradcliffe
Copy link
Contributor

  • Do only one thing
  • Non breaking API changes
  • Tested

What did this pull request do?

This change uses the pg_type table to get the real size of numeric column types like integer and bigint so that the automigration logic functions correctly.

NOTE: this change may trigger column type changes because the previous logic wasn't detecting column type size at all for some types.

For example: in Gorm v1 int fields were treated as 32-bit values (integer in postgresql); however, in v2 they are now 64-bit values (bigint). Because gorm couldn't extract a type size from the type name integer it did not detect that a schema change was needed. With this change, these fields would be migrated from integer to bigint.

User Case Description

I described the issue that we were hitting in this issue in the main gorm repo: go-gorm/gorm#4641

In brief: there are some column types that are currently always triggering an ALTER COLUMN during migration because gorm misidentifies the current size of the database column. This PR fixes that issue.

@@ -298,8 +304,9 @@ func (m Migrator) ColumnTypes(value interface{}) (columnTypes []gorm.ColumnType,
currentSchema, table := m.CurrentSchema(stmt, stmt.Table)
columns, err := m.DB.Raw(
"SELECT column_name, is_nullable, udt_name, character_maximum_length, "+
"numeric_precision, numeric_precision_radix, numeric_scale, datetime_precision "+
"FROM information_schema.columns WHERE table_catalog = ? AND table_schema = ? AND table_name = ?",
"numeric_precision, numeric_precision_radix, numeric_scale, datetime_precision, 8 * typlen "+
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do we need the 8 * typlen?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From looking at the code, the value produced by migrator.ColumnType.Length() is expected to be in bits, so we either need to multiply by 8 here or in the Length() accessor. I thought doing it in the SQL expression would be less confusing.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thank you for your pr.

@jinzhu jinzhu merged commit 6deb590 into go-gorm:master Sep 28, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants