id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
34320	Renaming fields with truncated names don't remove old constraints on Oracle.	Georgi Yanchev	Mohamed Nabil Rady	"**Steps to reproduce:**

1. Use Oracle as a db backend

2. Create a model class:
{{{
class TestModel(models.Model):
    looooooooooooooooooooooooooooooooooooooong_name = models.PositiveIntegerField(default=0)
}}}

3. python manage.py makemigrations
You get a migration file called 0001_initial.py with:
{{{
    operations = [
        migrations.CreateModel(
            name='TestModel',
            fields=[
                ('id', models.BigAutoField(auto_created=True, primary_key=True, serialize=False, verbose_name='ID')),
                ('looooooooooooooooooooooooooooooooooooooong_name', models.PositiveIntegerField(default=0)),
            ],
        ),
    ]

}}}

4. Rename the field in the model:
{{{
class TestModel(models.Model):
    renamed_looooooooooooooooooooooooooooooooooooooong_name = models.PositiveIntegerField(default=0)
}}}

5. python manage.py makemigrations
When asked about whether the field was renamed, say ""y"".
You get another migrations file 0002_rename_looooooooooooooooooooooooooooooooooooooong_name_testmodel_renamed_loooooooooooooooooooooooooo.py with:

{{{
    operations = [
        migrations.RenameField(
            model_name='testmodel',
            old_name='looooooooooooooooooooooooooooooooooooooong_name',
            new_name='renamed_looooooooooooooooooooooooooooooooooooooong_name',
        ),
    ]
}}}

6. Migrate db
python manage.py migrate myapp
The queries executed are:

{{{
-- 0001_....py
CREATE TABLE ""MYAPP_TESTMODEL"" (""ID"" NUMBER(19) GENERATED BY DEFAULT ON NULL AS IDENTITY NOT NULL PRIMARY KEY, ""LOOOOOOOOOOOOOOOOOOOOOOOOO8973"" NUMBER(11) NOT NULL CHECK (""LOOOOOOOOOOOOOOOOOOOOOOOOO8973"" >= 0))

-- 0002_....py
ALTER TABLE ""MYAPP_TESTMODEL"" RENAME COLUMN ""LOOOOOOOOOOOOOOOOOOOOOOOOO8973"" TO ""RENAMED_LOOOOOOOOOOOOOOOOOAFEA""
ALTER TABLE ""MYAPP_TESTMODEL"" ADD CONSTRAINT ""MYAPP_TES_RENAMED_L_7E971FCA_C"" CHECK (""RENAMED_LOOOOOOOOOOOOOOOOOAFEA"" >= 0)
}}}

**Note that we didn't create a constraint when applying 0001, but we did create one for 0002. So the db schema is not the same as it would be if 0001 and 0002 were squashed**

7. Unapply 0002 
python manage.py migrate myapp 0001
Queries are:
{{{
ALTER TABLE ""MYAPP_TESTMODEL"" RENAME COLUMN ""RENAMED_LOOOOOOOOOOOOOOOOOAFEA"" TO ""LOOOOOOOOOOOOOOOOOOOOOOOOO8973""
ALTER TABLE ""MYAPP_TESTMODEL"" ADD CONSTRAINT ""MYAPP_TES_LOOOOOOOO_D76B28D1_C"" CHECK (""LOOOOOOOOOOOOOOOOOOOOOOOOO8973"" >= 0)
}}}

**Note that MYAPP_TES_RENAMED_L_7E971FCA_C that was created when 0002 was applied is not dropped. So now we end up with 2 CONSTRAINTs.**

8. Apply 0002
python migrate myapp 0002

Queries are:

{{{
ALTER TABLE ""MYAPP_TESTMODEL"" RENAME COLUMN ""LOOOOOOOOOOOOOOOOOOOOOOOOO8973"" TO ""RENAMED_LOOOOOOOOOOOOOOOOOAFEA""
ALTER TABLE ""MYAPP_TESTMODEL"" ADD CONSTRAINT ""MYAPP_TES_RENAMED_L_7E971FCA_C"" CHECK (""RENAMED_LOOOOOOOOOOOOOOOOOAFEA"" >= 0)
}}}



**Observed:**

The last query fails with:

{{{
django.db.utils.DatabaseError: ORA-02264: name already used by an existing constraint
}}}



**Expected:**

1. Database schema is the same no matter whether a field was renamed.
2. Obsolete db CONSTRAINTs are dropped.

"	Bug	closed	Database layer (models, ORM)	4.1	Normal	fixed	oracle		Ready for checkin	1	0	0	0	0	0