No-op rename of field with `db_column` drops and recreates constraints/indexes.

[Jacob Walls]

With this model:

class MyModel(models.Model):
    foo = models.BooleanField(db_column="foobar")

    class Meta:
        constraints = [
            models.UniqueConstraint(
                fields=["foo"],
                name="unique_foo",
            ),
        ]

Suppose I wish to improve the name of the field so it agrees with the database column name:

class MyModel(models.Model):
    foobar = models.BooleanField(db_column="foobar")

    class Meta:
        constraints = [
            models.UniqueConstraint(
                fields=["foobar"],
                name="unique_foo",
            ),
        ]

That change generates a migration with this SQL, assuming you answer "was the field ... renamed..." with Yes:

BEGIN;
--
-- Remove constraint unique_foo from model mymodel
--
ALTER TABLE "models_mymodel" DROP CONSTRAINT "unique_foo";
--
-- Rename field foo on mymodel to foobar
--
-- (no-op)
--
-- Create constraint unique_foo on model mymodel
--
ALTER TABLE "models_mymodel" ADD CONSTRAINT "unique_foo" UNIQUE ("foobar");
COMMIT;

Suggesting that we compare on db_column if present to allow this kind of change to be a no-op with respect to constraints.

[Mariusz Felisiak]

Tentatively accepted.

[Giannis Terzopoulos]

I had a brief look at this and it seems related to #35038 and the suggestion to add a new ​AlterConstraint operation. So maybe it's best to have that operation in place before someone works on this ticket.

[Shubham Singh Sugara]

Replying to Giannis Terzopoulos:

I had a brief look at this and it seems related to #35038 and the suggestion to add a new ​AlterConstraint operation. So maybe it's best to have that operation in place before someone works on this ticket.

I commented on #35308 to see if issue is still there or some one is working on it
Maybe i can give it a try if no one else is trying , the old PR was closed due to solution not being right ,so lets see

[Ahmed Ibrahim]

I'm taking this if no one minds

[Jacob Walls]

Thanks, but before getting started I would evaluate if the situation has already been fixed in the ​PR for the closely related #35038. At the very least I would encourage branching off of that work.