makemigrations creates the same migration again and again (because it fails to compare uppercase to lowercase model names)

[Daniel Musketa]

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       │  

[Daniel Musketa]

I tested with several other versions and got the following weirdly unpredictable behaviour:

(django_1.7) $  for _ in {{1..10}}; do ./manage.py makemigrations; done
Migrations for 'app1':
  0003_auto_20160929_2012.py:
    - Alter field fk_to_model1 on model2
Migrations for 'app1':
  0004_auto_20160929_2012.py:
    - Alter field fk_to_model1 on model2
Migrations for 'app1':
  0005_auto_20160929_2012.py:
    - Alter field fk_to_model1 on model2
Migrations for 'app1':
  0006_auto_20160929_2012.py:
    - Alter field fk_to_model1 on model2
Migrations for 'app1':
  0007_auto_20160929_2012.py:
    - Alter field fk_to_model1 on model2
No changes detected
Migrations for 'app1':
  0008_auto_20160929_2012.py:
    - Alter field fk_to_model1 on model2
Migrations for 'app1':
  0009_auto_20160929_2012.py:
    - Alter field fk_to_model1 on model2
No changes detected
No changes detected

(django_1.8)$ for _ in {{1..20}}; do ./manage.py makemigrations; done
No changes detected
No changes detected
Migrations for 'app1':
  0003_auto_20160929_1957.py:
    - Alter field fk_to_model1 on model2
Migrations for 'app1':
  0004_auto_20160929_1957.py:
    - Alter field fk_to_model1 on model2
No changes detected
Migrations for 'app1':
  0005_auto_20160929_1957.py:
    - Alter field fk_to_model1 on model2
No changes detected
No changes detected
Migrations for 'app1':
  0006_auto_20160929_1957.py:
    - Alter field fk_to_model1 on model2
Migrations for 'app1':
  0007_auto_20160929_1957.py:
    - Alter field fk_to_model1 on model2
Migrations for 'app1':
  0008_auto_20160929_1957.py:
    - Alter field fk_to_model1 on model2
No changes detected
Migrations for 'app1':
  0009_auto_20160929_1957.py:
    - Alter field fk_to_model1 on model2
No changes detected
No changes detected
No changes detected
Migrations for 'app1':
  0010_auto_20160929_1957.py:
    - Alter field fk_to_model1 on model2
No changes detected
No changes detected
Migrations for 'app1':
  0011_auto_20160929_1957.py:
    - Alter field fk_to_model1 on model2

(django_1.9)$ for _ in {{1..10}}; do ./manage.py makemigrations; done
Migrations for 'app1':
  0003_auto_20160929_2010.py:
    - Alter field fk_to_model1 on model2
Migrations for 'app1':
  0004_auto_20160929_2010.py:
    - Alter field fk_to_model1 on model2
Migrations for 'app1':
  0005_auto_20160929_2010.py:
    - Alter field fk_to_model1 on model2
Migrations for 'app1':
  0006_auto_20160929_2010.py:
    - Alter field fk_to_model1 on model2
Migrations for 'app1':
  0007_auto_20160929_2010.py:
    - Alter field fk_to_model1 on model2
Migrations for 'app1':
  0008_auto_20160929_2010.py:
    - Alter field fk_to_model1 on model2
Migrations for 'app1':
  0009_auto_20160929_2010.py:
    - Alter field fk_to_model1 on model2
Migrations for 'app1':
  0010_auto_20160929_2010.py:
    - Alter field fk_to_model1 on model2
Migrations for 'app1':
  0011_auto_20160929_2010.py:
    - Alter field fk_to_model1 on model2
Migrations for 'app1':
  0012_auto_20160929_2010.py:
    - Alter field fk_to_model1 on model2