Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#30868 closed Bug (fixed)

ForeignKey's to_field parameter gets the old field's name when renaming a PrimaryKey.

Reported by: Carlos Leite Owned by: Simon Charette
Component: Migrations Version: dev
Severity: Normal Keywords: migration renamefield to_field
Cc: Simon Charette Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

Having these two models

class ModelA(models.Model):
    field_wrong = models.CharField('field1', max_length=50, primary_key=True)  # I'm a Primary key.

class ModelB(models.Model):
    field_fk = models.ForeignKey(ModelA, blank=True, null=True, on_delete=models.CASCADE)  

... migrations applyed ...

the ModelA.field_wrong field has been renamed ... and Django recognizes the "renaming"

# Primary key renamed
class ModelA(models.Model):
    field_fixed = models.CharField('field1', max_length=50, primary_key=True)  # I'm a Primary key.

Attempts to to_field parameter.

The to_field points to the old_name (field_typo) and not to the new one ("field_fixed")

class Migration(migrations.Migration):

    dependencies = [
        ('app1', '0001_initial'),
    ]

    operations = [
        migrations.RenameField(
            model_name='modela',
            old_name='field_wrong',
            new_name='field_fixed',
        ),
        migrations.AlterField(
            model_name='modelb',
            name='modela',
            field=models.ForeignKey(blank=True, null=True, on_delete=django.db.models.deletion.CASCADE, to='app1.ModelB', to_field='field_wrong'),
        ),
    ]

Change History (7)

comment:1 by Mariusz Felisiak, 4 years ago

Cc: Simon Charette added
Easy pickings: unset
Severity: Release blockerNormal
Summary: ForeignKey's "to_field" parameter gets the old field's name when renaming a PrimaryKeyForeignKey's to_field parameter gets the old field's name when renaming a PrimaryKey.
Triage Stage: UnreviewedAccepted
Version: 2.2master

Thanks for this ticket. It looks like a regression in dcdd219ee1e062dc6189f382e0298e0adf5d5ddf, because an AlterField operation wasn't generated in such cases before this change (and I don't think we need it).

comment:2 by Simon Charette, 4 years ago

Owner: changed from nobody to Simon Charette
Status: newassigned

comment:3 by Simon Charette, 4 years ago

Has patch: set
Last edited 4 years ago by Mariusz Felisiak (previous) (diff)

comment:4 by Mariusz Felisiak <felisiak.mariusz@…>, 4 years ago

Resolution: fixed
Status: assignedclosed

In 2839659b:

Fixed #30868 -- Prevented unnecessary AlterField when renaming a referenced pk.

Regression introduced by dcdd219ee1, refs #25817.

Thanks Carlos E. C. Leite for the report and Mariusz for the bisect.

comment:5 by Mariusz Felisiak <felisiak.mariusz@…>, 4 years ago

In bab3ad5:

[3.0.x] Fixed #30868 -- Prevented unnecessary AlterField when renaming a referenced pk.

Regression introduced by dcdd219ee1, refs #25817.

Thanks Carlos E. C. Leite for the report and Mariusz for the bisect.

Backport of 2839659b42ef80038152768b6cedae1016c59d90 from master

comment:6 by Harro, 4 years ago

Should this be backported to the 2.x branch too?

Seems the same issue is there.

comment:7 by Mariusz Felisiak, 4 years ago

Unfortunately this patch doesn't qualify for a backport.

Note: See TracTickets for help on using tickets.
Back to Top