#27297: infinite AlterField migrations created for foreign key after case-only
model name change
--------------------------------+------------------------------------
Reporter: Daniel Musketa | Owner: nobody
Type: Bug | Status: new
Component: Migrations | Version: 1.10
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
--------------------------------+------------------------------------
Old description:
> Tested and affected Django versions:
> - 1.7
> - 1.8
> - 1.9
> - 1.9.6
> - 1.10.1
>
> I created a minimal working example to reproduce this
> behaviour: https://github.com/vlt/migrations
>
> When you run {{{./manage.py makemigrations}}} it will create
> the following migration over and over again:
>
> {{{
> Migrations for 'app1':
> 0003_auto_20160929_1358.py:
> - Alter field fk_to_model1 on model2
> }}}
>
> The new file {{{0003_auto_20160929_1358.py}}}:
>
> {{{
> # -*- coding: utf-8 -*-
> # Generated by Django 1.10.1 on 2016-09-29 13:58
> from __future__ import unicode_literals
>
> from django.db import migrations, models
> import django.db.models.deletion
>
> class Migration(migrations.Migration):
>
> dependencies = [
> ('app1', '0002_add_model2'),
> ]
>
> operations = [
> migrations.AlterField(
> model_name='model2',
> name='fk_to_model1',
> field=models.ForeignKey(on_delete=django.db.models.deletion.CASCADE,
> to='app1.Model1'),
> ),
> ]
> }}}
>
> The #django conversation that led to this ticket:
>
> {{{
> 11:20:01 vlt | Another question: What stupid thing │
> | could I have done that causes │
> | makemigrations (v 1.9.6 and 1.10.1) │
> | to create the very same AlterField() │
> | migration over and over again │
> | everytime I run that command? (I’ll │
> | try to create an MWE.) │
> 11:22:10 vlt | $ for _ in {{1..10}}; do ./manage.py │
> | makemigrations; done │
> 11:22:24 vlt | That will produce 10 new migrations │
> | files. All looking the same. │
> 11:22:28 vlt | :-D │
> 11:37:46 +bmispelon | vlt: what does the migration look │
> | like? │
> 11:50:56 vlt | This is what every of the previous 25 │
> | migrations looks like: │
> | https://dpaste.de/wS4z (except for │
> | the dependencies, of course) │
> 11:52:13 +bmispelon | vlt: strange. What does the model │
> | look like? │
> 11:54:44 vlt | bmispelon: https://dpaste.de/rWGf │
> 11:55:21 vlt | bmispelon: Maybe it’s caused by the │
> | @property def name() ... weirdness. │
> 11:58:27 +bmispelon | vlt: I can't reproduce your issue on │
> | my machine (I copied the same model │
> | you pasted but when I run │
> | makemigrations a second time, it │
> | doesn't detect new changes) │
> 11:58:36 +bmispelon | vlt: which version of Python/Django │
> | are you using? │
> 11:59:29 vlt | bmispelon: Created the project on │
> | 1.10.1 (3.4), verified the migration │
> | zombies also on 1.9.6 (3.4). │
> 12:00:02 vlt | bmispelon: I tried to reproduce with │
> | a smaller model without success. │
> 12:00:16 vlt | bmispelon: I’ll paste the existing │
> | migrations … │
> 12:01:01 +apollo13 | vlt: name shouldn't affect anything, │
> | since it is a normal python variable │
> | and not migration related in any way │
> 12:02:03 +bmispelon | (I still can't reproduce the issue. I │
> | tried creating the migration under │
> | 1.10 then switching to 1.9 and I │
> | still get "no changes detected") │
> 12:09:44 vlt | bmispelon, apollo13: │
> | http://77up.space/migrations.tar │
> 12:31:30 vlt | bmispelon: Can you reproduce the │
> | migration behaviour using the │
> | migrations.tar I uploaded? │
> 12:36:12 +bmispelon | vlt: as a matter of fact, I can │
> 12:40:47 +bmispelon | vlt: something weird is definitely │
> | going on... First I thought it might │
> | be because your app is called "name" │
> | but I changed that and I still see │
> | the same behavior │
> 12:47:50 +bmispelon | vlt: I don't understand what's going │
> | on here, sorry :( │
> 12:48:16 +bmispelon | I'll see if I can narrow down the │
> | reproduction steps later today │
> 14:18:02 vlt | Hello again. I created a minimal │
> | working example for the weird │
> | migrations thing: │
> | https://github.com/vlt/migrations If │
> | you run makemigrations it will create │
> | the very same one over and over │
> | again. │
> 14:18:47 +apollo13 | lets see │
> 14:19:27 +apollo13 | vlt: indeed │
> 14:28:00 +apollo13 | vlt: oh │
> 14:29:57 +apollo13 | vlt: seems like a bug, it compares │
> | app1.Model1 to app1.model1 -- please │
> | open a ticket with that information │
> 14:30:18 +apollo13 | somehwere a .lower() is missing │
> }}}
New description:
Tested and affected Django versions:
- 1.7
- 1.8
- 1.9
- 1.9.6
- 1.10.1
A ''case-only'' rename of a model is not detected. This leads to infinite
migrations on a foreign key field that refers to the renamed model.
I created a minimal working example to reproduce this
behaviour: https://github.com/vlt/django_ticket_27297_capitalization
When you run {{{./manage.py makemigrations}}} it will create
the following migration over and over again:
{{{
Migrations for 'app1':
app1/migrations/0003_auto_20161001_2136.py:
- Alter field fk_to_model1 on model2
}}}
The new file {{{0003_auto_20161001_2136.py}}}:
{{{
# -*- coding: utf-8 -*-
# Generated by Django 1.10.2 on 2016-10-01 21:36
from __future__ import unicode_literals
from django.db import migrations, models
import django.db.models.deletion
class Migration(migrations.Migration):
dependencies = [
('app1', '0002_model2'),
]
operations = [
migrations.AlterField(
model_name='model2',
name='fk_to_model1',
field=models.ForeignKey(on_delete=django.db.models.deletion.CASCADE,
to='app1.moDEl1'),
),
]
}}}
I have no idea why the Autodetector in migrations uses lower() in he first
place.
--
Comment (by Daniel Musketa):
I narrowed down the cause, created a new example and changed the ticket
description accordingly.
--
Ticket URL: <https://code.djangoproject.com/ticket/27297#comment:5>
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 [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/061.538eb300065ba4634dcdbd55f5f04804%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
