Opened 8 years ago
Last modified 8 years ago
#27297 closed Bug
makemigrations creates the same migration again and again (because it fails to compare uppercase to lowercase model names) — at Initial Version
Reported by: | Daniel Musketa | Owned by: | nobody |
---|---|---|---|
Component: | Migrations | Version: | dev |
Severity: | Normal | Keywords: | |
Cc: | daniel.musketa@…, desecho@… | Triage Stage: | Accepted |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
Tested and affected Django versions:
- 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 │
Note:
See TracTickets
for help on using tickets.