gorm icon indicating copy to clipboard operation
gorm copied to clipboard

AutoMigrate will not update changed `default` value for primary keys

Open deefdragon opened this issue 2 years ago • 6 comments

GORM Playground Link

https://github.com/go-gorm/playground/pull/716

Description

I recently changed all of my tables to use a default for the UUID primary key so that if I forget to set a value, the default takes over and generates a UUID for me. Specifically, this is for the primary keys (I have tested my example with non primary keys and changing/adding a default works fine). I have tested this example with postgres 15.

//create a struct such as this (Notice the UUID primary key)
type Example struct {
	CreatedAt *time.Time      `json:"-"`
	DeletedAt *gorm.DeletedAt `gorm:"index" json:"-"`
	UpdatedAt *time.Time      `json:"UpdatedAt,omitempty,format:unix"`
	UUID      uuid.UUID       `gorm:"primarykey;type:uuid" json:"UUID"`
	Data string
}

//migrate the struct
lc.Gorm.AutoMigrate(&Example{})

//Update Example struct to the following (notice the addition of the default to UUID)
type Example struct {
	CreatedAt *time.Time      `json:"-"`
	DeletedAt *gorm.DeletedAt `gorm:"index" json:"-"`
	UpdatedAt *time.Time      `json:"UpdatedAt,omitempty,format:unix"`
	UUID uuid.UUID `gorm:"primarykey;type:uuid;default:gen_random_uuid()" json:"UUID"`
	Data string
}

lc.Gorm.AutoMigrate(&Example{})

After checking the database table data (via pgadmin), the default of UUID has not been changed, and is still empty.

From my perusal of the migrator code, this lack of change appears to be the case due to the !field.PrimaryKey check here, which makes it appear intentional, but I was not able to find any documentation of this limitation, or reasoning as to why this limit exists. Its even stranger as you can set the default for a primary key on table creation.

Is it possible this check was made to prevent setting default:someConst for the primary key?

deefdragon avatar Apr 15 '24 00:04 deefdragon

The issue has been automatically marked as stale as it missing playground pull request link, which is important to help others understand your issue effectively and make sure the issue hasn't been fixed on latest master, checkout https://github.com/go-gorm/playground for details. it will be closed in 30 days if no further activity occurs. if you are asking question, please use the Question template, most likely your question already answered https://github.com/go-gorm/gorm/issues or described in the document https://gorm.io ✨ Search Before Asking

github-actions[bot] avatar Apr 15 '24 02:04 github-actions[bot]

Yes, this is intentional, migrating primary keys is a dangerous practice. We should describe it clearly in the documentation

a631807682 avatar Apr 22 '24 08:04 a631807682

would it be possible to add a clause or some other flag to allow migrating the primary key? Having a protective default to not do so makes sense, but there are cases where it is desired, and where the user has their own protection in place/is willing to take the risk.

deefdragon avatar Apr 22 '24 17:04 deefdragon

You can use AlterColumn to change it. Migrating the primary key is a relatively complex and dangerous operation. It may be a foreign key to another table, which may require confirmation of the order of table changes and transactions involved. Even so, there may still be other tables that are not declared in the same process. Usually in the early stages of development we can recreate it with DropTable and AutoMigrate. Your suggestion may be possible, but we may need to confirm that this will bring enough benefits.

a631807682 avatar Apr 23 '24 03:04 a631807682

This issue has been automatically marked as stale because it has been open 360 days with no activity. Remove stale label or comment or this will be closed in 180 days

github-actions[bot] avatar Apr 19 '25 02:04 github-actions[bot]

I just hit this problem, please add it to the docs. Or maybe fail in AutoMigration if PK change is required?

MonstraG avatar May 22 '25 17:05 MonstraG