Changes between Version 1 and Version 5 of Ticket #27297


Ignore:
Timestamp:
Oct 1, 2016, 4:40:17 PM (8 years ago)
Author:
Daniel Musketa
Comment:

I narrowed down the cause, created a new example and changed the ticket description accordingly.

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #27297

    • Property Triage Stage Unreviewed → Accepted
    • Property Summary makemigrations creates the same migration again and again (because it fails to compare uppercase to lowercase model names) → infinite AlterField migrations created for foreign key after case-only model name change

  • Ticket #27297 – Description

    v1 v5  
    66- 1.10.1
    77
     8
     9A ''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.
     10
    811I created a minimal working example to reproduce this
    9 behaviour: https://github.com/vlt/migrations
     12behaviour: https://github.com/vlt/django_ticket_27297_capitalization
    1013
    1114When you run {{{./manage.py makemigrations}}} it will create
    … …  
    1417{{{
    1518Migrations for 'app1':
    16   0003_auto_20160929_1358.py:
     19  app1/migrations/0003_auto_20161001_2136.py:
    1720    - Alter field fk_to_model1 on model2
    1821}}}
    1922
    20 The new file {{{0003_auto_20160929_1358.py}}}:
     23The new file {{{0003_auto_20161001_2136.py}}}:
    2124
    2225{{{
    2326# -*- coding: utf-8 -*-
    24 # Generated by Django 1.10.1 on 2016-09-29 13:58
     27# Generated by Django 1.10.2 on 2016-10-01 21:36
    2528from __future__ import unicode_literals
    2629
    … …  
    3235
    3336    dependencies = [
    34         ('app1', '0002_add_model2'),
     37        ('app1', '0002_model2'),
    3538    ]
    3639
    … …  
    3942            model_name='model2',
    4043            name='fk_to_model1',
    41             field=models.ForeignKey(on_delete=django.db.models.deletion.CASCADE, to='app1.Model1'),
     44            field=models.ForeignKey(on_delete=django.db.models.deletion.CASCADE, to='app1.moDEl1'),
    4245        ),
    4346    ]
    4447}}}
    4548
    46 The #django conversation that led to this ticket:
    47 
    48 {{{
    49 11:20:01         vlt | Another question: What stupid thing   │
    50                      | could I have done that causes         │
    51                      | makemigrations (v 1.9.6 and 1.10.1)   │ 
    52                      | to create the very same AlterField()  │ 
    53                      | migration over and over again         │ 
    54                      | everytime I run that command? (I’ll   │
    55                      | try to create an MWE.)                │ 
    56 11:22:10         vlt | $ for _ in {{1..10}}; do ./manage.py  │ 
    57                      | makemigrations; done                  │ 
    58 11:22:24         vlt | That will produce 10 new migrations   │ 
    59                      | files. All looking the same.          │ 
    60 11:22:28         vlt | :-D                                   │ 
    61 11:37:46  +bmispelon | vlt: what does the migration look     │ 
    62                      | like?                                 │ 
    63 11:50:56         vlt | This is what every of the previous 25 │ 
    64                      | migrations looks like:                │ 
    65                      | https://dpaste.de/wS4z  (except for   │ 
    66                      | the dependencies, of course)          │ 
    67 11:52:13  +bmispelon | vlt: strange. What does the model     │ 
    68                      | look like?                            │ 
    69 11:54:44         vlt | bmispelon: https://dpaste.de/rWGf     │ 
    70 11:55:21         vlt | bmispelon: Maybe it’s caused by the   │
    71                      | @property def name() ... weirdness.   │ 
    72 11:58:27  +bmispelon | vlt: I can't reproduce your issue on  │
    73                      | my machine (I copied the same model   │ 
    74                      | you pasted but when I run             │ 
    75                      | makemigrations a second time, it      │ 
    76                      | doesn't detect new changes)           │ 
    77 11:58:36  +bmispelon | vlt: which version of Python/Django   │ 
    78                      | are you using?                        │ 
    79 11:59:29         vlt | bmispelon: Created the project on     │ 
    80                      | 1.10.1 (3.4), verified the migration  │ 
    81                      | zombies also on 1.9.6 (3.4).          │ 
    82 12:00:02         vlt | bmispelon: I tried to reproduce with  │ 
    83                      | a smaller model without success.      │ 
    84 12:00:16         vlt | bmispelon: I’ll paste the existing    │
    85                      | migrations …                          │
    86 12:01:01   +apollo13 | vlt: name shouldn't affect anything,  │ 
    87                      | since it is a normal python variable  │ 
    88                      | and not migration related in any way  │ 
    89 12:02:03  +bmispelon | (I still can't reproduce the issue. I │ 
    90                      | tried creating the migration under    │ 
    91                      | 1.10 then switching to 1.9 and I      │ 
    92                      | still get "no changes detected")      │ 
    93 12:09:44         vlt | bmispelon, apollo13:                  │ 
    94                      | http://77up.space/migrations.tar      │ 
    95 12:31:30         vlt | bmispelon: Can you reproduce the      │ 
    96                      | migration behaviour using the         │ 
    97                      | migrations.tar I uploaded?            │ 
    98 12:36:12  +bmispelon | vlt: as a matter of fact, I can       │ 
    99 12:40:47  +bmispelon | vlt: something weird is definitely    │ 
    100                      | going on... First I thought it might  │ 
    101                      | be because your app is called "name"  │ 
    102                      | but I changed that and I still see    │ 
    103                      | the same behavior                     │ 
    104 12:47:50  +bmispelon | vlt: I don't understand what's going  │ 
    105                      | on here, sorry :(                     │ 
    106 12:48:16  +bmispelon | I'll see if I can narrow down the     │ 
    107                      | reproduction steps later today        │ 
    108 14:18:02         vlt | Hello again. I created a minimal      │ 
    109                      | working example for the weird         │ 
    110                      | migrations thing:                     │ 
    111                      | https://github.com/vlt/migrations  If │ 
    112                      | you run makemigrations it will create │ 
    113                      | the very same one over and over       │ 
    114                      | again.                                │ 
    115 14:18:47   +apollo13 | lets see                              │ 
    116 14:19:27   +apollo13 | vlt: indeed                           │ 
    117 14:28:00   +apollo13 | vlt: oh                               │ 
    118 14:29:57   +apollo13 | vlt: seems like a bug, it compares    │ 
    119                      | app1.Model1 to app1.model1 -- please  │ 
    120                      | open a ticket with that information   │ 
    121 14:30:18   +apollo13 | somehwere a .lower() is missing       │ 
    122 }}}
     49I have no idea why the Autodetector in migrations uses lower() in he first place.
Back to Top