#27768: makemigrations uses unnecessary AddField for ForeignKey depending on
model
name
----------------------------+--------------------------------------
Reporter: Ed Morley | Owner: nobody
Type: Bug | Status: new
Component: Migrations | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
----------------------------+--------------------------------------
Description changed by Ed Morley:
Old description:
> Using Django master, for this model `makemigrations` generates an
> inefficient migrations file, which uses a combination of `CreateModel`
> and `AddField`, rather than just using a single `CreateModel` operation.
>
> {{{#!python
> class Aaa(models.Model):
> pass
>
> class Foo(models.Model):
> fk = models.ForeignKey(Aaa,
> on_delete=django.db.models.deletion.CASCADE)
> }}}
>
> Resultant migration operations generated by `./manage.py makemigrations`:
> {{{#!python
> operations = [
> migrations.CreateModel(
> name='Foo',
> fields=[
> ('id', models.AutoField(auto_created=True,
> primary_key=True, serialize=False, verbose_name='ID')),
> ],
> ),
> migrations.CreateModel(
> name='Zzz',
> fields=[
> ('id', models.AutoField(auto_created=True,
> primary_key=True, serialize=False, verbose_name='ID')),
> ],
> ),
> migrations.AddField(
> model_name='foo',
> name='fk',
> field=models.ForeignKey(on_delete=django.db.models.deletion.CASCADE,
> to='testapp.Zzz'),
> ),
> ]
> }}}
>
> However if the `Zzz` model was instead called `Aaa`, then the migration
> file is correctly optimised (ie: the `ForeignKey` is defined within the
> `CreateModel` operation):
> {{{#!python
> operations = [
> migrations.CreateModel(
> name='Aaa',
> fields=[
> ('id', models.AutoField(auto_created=True,
> primary_key=True, serialize=False, verbose_name='ID')),
> ],
> ),
> migrations.CreateModel(
> name='Foo',
> fields=[
> ('id', models.AutoField(auto_created=True,
> primary_key=True, serialize=False, verbose_name='ID')),
> ('fk',
> models.ForeignKey(on_delete=django.db.models.deletion.CASCADE,
> to='testapp.Aaa')),
> ],
> ),
> ]
> }}}
>
> Ideally the optimizer would either just use the order as defined in
> models.py (which would at least allow for users to order them sensibly),
> or else intelligently sort the models such that those with no (or fewer)
> foreign keys are listed in `operations` first, thereby reducing the
> number of cases where the FK has to be added in a separate `AddField`
> operation.
New description:
Using Django master, for this model `makemigrations` generates an
inefficient migrations file, which uses a combination of `CreateModel` and
`AddField`, rather than just using a single `CreateModel` operation.
{{{#!python
class Zzz(models.Model):
pass
class Foo(models.Model):
fk = models.ForeignKey(Zzz,
on_delete=django.db.models.deletion.CASCADE)
}}}
Resultant migration operations generated by `./manage.py makemigrations`:
{{{#!python
operations = [
migrations.CreateModel(
name='Foo',
fields=[
('id', models.AutoField(auto_created=True,
primary_key=True, serialize=False, verbose_name='ID')),
],
),
migrations.CreateModel(
name='Zzz',
fields=[
('id', models.AutoField(auto_created=True,
primary_key=True, serialize=False, verbose_name='ID')),
],
),
migrations.AddField(
model_name='foo',
name='fk',
field=models.ForeignKey(on_delete=django.db.models.deletion.CASCADE,
to='testapp.Zzz'),
),
]
}}}
However if the `Zzz` model was instead called `Aaa`, then the migration
file is correctly optimised (ie: the `ForeignKey` is defined within the
`CreateModel` operation):
{{{#!python
operations = [
migrations.CreateModel(
name='Aaa',
fields=[
('id', models.AutoField(auto_created=True,
primary_key=True, serialize=False, verbose_name='ID')),
],
),
migrations.CreateModel(
name='Foo',
fields=[
('id', models.AutoField(auto_created=True,
primary_key=True, serialize=False, verbose_name='ID')),
('fk',
models.ForeignKey(on_delete=django.db.models.deletion.CASCADE,
to='testapp.Aaa')),
],
),
]
}}}
Ideally the optimizer would either just use the order as defined in
models.py (which would at least allow for users to order them sensibly),
or else intelligently sort the models such that those with no (or fewer)
foreign keys are listed in `operations` first, thereby reducing the number
of cases where the FK has to be added in a separate `AddField` operation.
--
--
Ticket URL: <https://code.djangoproject.com/ticket/27768#comment:2>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/066.e24e84dc3b8bbf625e3a61e9d6d0c77c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
