Gorm 1.2.7 breaks migrations when updating 1.2.5

Playground link doesn't make any sense, as I'd need to use multiple versions at once.

Say you have the following model:

type User struct {
    BaseModel

    // The user's email address
    Email                    string        `gorm:"not null;uniqueIndex:idx_user_email" json:"email"`
}

Migrating with:

tx.AutoMigrate(&domain.User{})

Causes:

2024/03/10 22:09:04  ERROR: constraint "uni_users_email" of relation "users" does not exist (SQLSTATE 42704)
[0.697ms] [rows:0] ALTER TABLE "users" DROP CONSTRAINT "uni_users_email"

I'd appreciate, if releases would be properly tested beforehand. I'll be pinning 1.2.5 for now.

link for not being marked as stale: https://github.com/go-gorm/playground/issues/0

Comment From: github-actions[bot]

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 ✨

Comment From: ChristianSch

v1.25.7-0.20240204074919-46816ad31dde works

Comment From: github-actions[bot]

Comment From: klipach

Have the same issue while using v1.25.9 and PostgreSQL. Downgrading to v1.25.5 resolves the issue.

Comment From: github-actions[bot]

Comment From: zetaab

we are also seeing this

2024/04/09 05:52:14  pq: constraint "uni_image_statistics_image_id" of relation "image_statistics" does not exist
[0.955ms] [rows:0] ALTER TABLE "image_statistics" DROP CONSTRAINT "uni_image_statistics_image_id"

"error":"pq: constraint \"uni_image_statistics_image_id\" of relation \"image_statistics\" does not exist"

using gorm 1.25.9 and gorm postgres 1.5.7

in our case the model is

type ImageStatistics struct {
    Model                      `json:"-"`
    ImageID                    string         `json:"image_id" gorm:"index:idx_image_id,unique"`
...
}

Comment From: github-actions[bot]

Comment From: UninspiredNickname

I can confirm that - this error happens because in https://github.com/go-gorm/gorm/blob/v1.25.9/migrator/migrator.go#L569 field.Unique returns false when UniqueIndex is used on the models Simply swapping it to unique;index fixed the problem for me, but field.Unique should be set to true if uniqueIndex is used

Comment From: varfrog

I wish this library: 1. used proper versioning - semver 2.0.0 or go's /vX for breaking changes 2. had a changelog 3. test the changes big asks fsho... I don't expect any of these to be implemented though. Who versions their libraries anyways... changelog? c'mon...

Comment From: github-actions[bot]

Comment From: PaulSonOfLars

+1 on this issue. Also noticed this upon upgrading from 1.25.5 to 1.25.9.

This may be helpful for debugging the root cause - I noticed that creating tables on 1.25.5 and 1.25.9 results in different table metadata, which is likely related. Looking at the \d+ output of a table: - 1.25.5 creates an idx_<table>_<column> index, as a UNIQUE CONSTRAINT. - 1.25.9 creates an idx_<column> index, but only as UNIQUE; not as a constraint.

Comment From: github-actions[bot]

Comment From: ChristianSch

Not stale. Doesn't look fixed to me. @jinzhu

Comment From: github-actions[bot]

Comment From: PaulSonOfLars

If all it wants is a playground link... Will this work? https://github.com/go-gorm/playground/issues/0

Comment From: github-actions[bot]

Comment From: ChristianSch

Lol this bot is stupid. I added the playground link to the first message ...

Comment From: github-actions[bot]

Comment From: varfrog

Lol this bot is stupid. I added the playground link to the first message ...

What it needs is a link to a pull request in the playground repo. See example how it is here: https://github.com/go-gorm/gorm/issues/6963 - it links to a playground PR where the PR code is a reproducer for the bug

Comment From: github-actions[bot]

Comment From: ChristianSch

@varfrog that ticket is marked as stale as well. I don't understand how and why I'd even want to open a PR to anywhere for this topic.

As I'm migrating off of this library, I'll also unsubscribe to this PR. Gorm is not something I'm interested in using anymore.

Comment From: klipach

@ChristianSch do you know some good alternatives? I'm also planning to migrate to some other tool

Comment From: github-actions[bot]

Comment From: ChristianSch

@klipach pgx + scany is what I'm using

Comment From: github-actions[bot]

Comment From: Sophie1142

I am also encountering this issue after upgrading from v1.25.5 to v1.25.9. The (abbreviated) definition of my model is:

type Service struct {
    gorm.Model
    Name string      `json:"name"`
    Nickname string  `gorm:"default:NULL;uniqueIndex;check:((nickname IS NOT NULL AND NOT nickname = '' AND nickname ~ '^[a-z0-9_-]+$') OR quick_quote_config_id IS NULL)"`
    ConfigID *uint   `json:"-" gorm:"default:null;check:chk_services_config,(config_id IS NOT NULL OR nickname IS NULL)"`
    Config   *Config `json:"-"``
}

Pinning to v1.25.5 solved my issue.

Comment From: github-actions[bot]

Comment From: PaulSonOfLars

Requesting to reopen this @jinzhu - this is a breaking change that is impacting multiple people

Comment From: zetaab

we are migrating away from gorm, there has been too many issues like this. Our weapon of choice is go-migrate and sqlx.

Comment From: abhijit-hota

The versioning in this library is so cursed. Just got hit by what seemed like a patched version. (1.25.2 -> 1.25.10)

Comment From: wchargin

We're also hitting this. I'm trying to upgrade past v1.25.12 to get the concurrency fixes in #7142 and #7435, since that's causing deadlocks in production. But trying to upgrade causes 'constraint "uni_..." of relation "..." does not exist (SQLSTATE 42704)' errors that I can't seem to shake. I tried manually adding and removing unique constraints and indices in my database instance, but couldn't even find a workaround.

How are we supposed to use newer versions of Gorm if we have a production database with a unique index that we can't just delete?

Comment From: traviswt

@wchargin if you are using "uniqueIndex" in your gorm tag you will run into this issue. Just change your tags to this instead "index:,unique" or if you want to name your index explicitly use "index:idx_name,unique".

Comment From: wchargin

@wchargin if you are using "uniqueIndex" in your gorm tag you will run into this issue. Just change your tags to this instead "index:,unique" or if you want to name your index explicitly use "index:idx_name,unique".

I am indeed using uniqueIndex.

I tried switching to:

index:,unique
index:idx_thetable_thecolumn,unique
index:uni_thetable_thecolumn,unique
no index/uniqueIndex directive at all

…but none of these resolved the problem. In every case I still see: ERROR: constraint "uni_thetable_thecolumn" of relation "thetable" does not exist.

I'm running Gorm v1.26.1, upgrading from Gorm v1.25.6.

I would love a workaround like this if we can get one to work, but I haven't found one yet.

Comment From: traviswt

darn, sorry to hear, I was able to resolve this last year by what I suggested.

Not ideal, but on new components I'm not using gorm, instead i'm using https://entgo.io/ and atlas for migrations. I find the code generation flow much better since it is very clear what is going on and I haven't had any of these problematic auto-migration issues.

Comment From: wchargin

<3 thank you for chiming in; I appreciate hearing what worked for you, and I'm glad that you were able to resolve it. I'll post back if I get something working. I may have a lead on manually replacing all the UNIQUE constraints with UNIQUE indices, gnarly as it is to do across environments.

(I definitely also prefer clear, explicit migrations to the auto-migration philosophy… thanks for the Entgo reference.)

Comment From: ian-leeming

I also had this issue with postgres after upgrading gorm from v1.25.4 to v1.30.0 and the postgres driver from v1.5.2 to v1.6.0.

The workaround in my case was to add unique; to the tag.

So I went from a tag like this: gorm:"not null;uniqueIndex:idx_apiuser_username,type:btree,option:CONCURRENTLY"

to a tag like this gorm:"not null;unique;uniqueIndex:idx_apiuser_username,type:btree,option:CONCURRENTLY"