#25830 closed Bug (invalid)
Unnecessary migrations with Python3
Reported by: | Torsten Bronger | Owned by: | nobody |
---|---|---|---|
Component: | Migrations | Version: | 1.8 |
Severity: | Normal | Keywords: | |
Cc: | bronger@… | Triage Stage: | Unreviewed |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
With Python3, "manage.py makemigrations" may under certain circumstances never be satisfied and always wants to create new migrations.
Steps to reproduce:
git clone https://github.com/juliabase/juliabase.git cd juliabase python3 manage.py makemigrations institute python3 manage.py makemigrations institute python3 manage.py makemigrations institute ...
Every time "makemigrations" is called, a new migration file is created. Apparently, Django+Python3 does not recognise that the Meta options of the latest migration and the current model classes are equivalent.
Change History (4)
comment:1 by , 9 years ago
comment:2 by , 9 years ago
Please provide a reduced set of models for your issue.
Your project is really big and has a ton of unspecified dependencies which makes it really hard to reproduce what you're describing.
I hacked around and managed to reproduce the "infinite migration" problem you're describing and I believe it might be caused by your generate_permissions
function.
If I remove the custom permissions in https://github.com/juliabase/juliabase/blob/master/institute/models/depositions.py#L58, then the migration autodetector stops detecting that model.
comment:3 by , 9 years ago
Resolution: | → invalid |
---|---|
Status: | new → closed |
I think I got it.
In your generate_permissions
function, you're iterating over a set. In recent versions of Python, the iteration order of sets (and dictionaries) is randomized and will change between separate runs.
Because of this, the order of you model's permissions is different every time so the autodetector picks up that change.
I don't believe that's a bug in Django's code. Changing from a set to a tuple in your code should fix the issue for you.
Thanks.
This may be because the definition of models changes every time you run the project e.g. using
default=timezone.now()
instead ofdefault=timezone.now
will trigger this behavior.Can you provide one of the migrations? This will make it easier to see what changes and whether it's a bug in your code or in Django.