Gorm 更新了 1.25.7 后出现报错

更新了 1.25.7 后出现报错 2024/02/21 10:23:33 ERROR: constraint "uni_users_name" of relation "users" does not exist (SQLSTATE 42704)

[0.525ms] [rows:0] ALTER TABLE "users" DROP CONSTRAINT "uni_users_name" 2024/02/21 10:23:33 ERROR: constraint "uni_users_name" of relation "users" does not exist (SQLSTATE 42704)

The document you expected this should be explained

Expected answer

Comment From: black-06

Could you reproduce it on the gorm-playground?

Comment From: czarny245

same issue, have to go back to 1.25.6

Comment From: KaitoXCode

I am also experiencing the same. revert to prev patch

EDIT: our pervious patch was 1.25.5

Comment From: aloknikhil

Same issue for us and we had to go back to 1.25.5 for this. Also, this only manifests when using existing data. So tests that setup a brand new DB and auto-migrate don't catch this. We also use Postgres

Eg of an existing unique key name looks like -> idx_abcd_archive_key 1.25.6 and 1.25.7 seem to be looking for -> uni_abcd_archive_key instead

Comment From: ywgx

I understand the source of the problem now.

For instance, in two tables, users and keys, both have defined:

    SecretKey      string        `gorm:"size:128;not null;uniqueIndex:uk_secret_key"`

In the older version, it would generate different constraint names by default, such as idx_users_secret_key and idx_keys_secret_key.

However, in the newer version, the constraint name strictly adheres to the definition, meaning there is only one uk_secret_key. This causes an error on startup, stating that uni_users_name cannot be found. In addition, another issue arises due to the strict adherence to the definition. Only the users table generates the constraint condition, while the keys table does not.

The solution to this problem is to delete the old constraint conditions, and when defining the constraint names in different tables, ensure that the names are unique.