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

AutoMigrate will not update changed default value for primary keys #6963

Open
deefdragon opened this issue Apr 15, 2024 · 4 comments
Open

AutoMigrate will not update changed default value for primary keys #6963

deefdragon opened this issue Apr 15, 2024 · 4 comments
Assignees

Comments

@deefdragon
Copy link

deefdragon commented Apr 15, 2024

GORM Playground Link

go-gorm/playground#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?

@github-actions github-actions bot added the type:missing reproduction steps missing reproduction steps label Apr 15, 2024
Copy link

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.ioSearch Before Asking

@github-actions github-actions bot added status:stale type:with reproduction steps with reproduction steps and removed type:missing reproduction steps missing reproduction steps labels Apr 15, 2024
@a631807682
Copy link
Member

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

@deefdragon
Copy link
Author

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.

@a631807682
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants