Possible bug: makemigrations caching prior migrations after deletion

[Yo-Yo Ma]

Using Python 3.4.2 and Django @stable/1.8.x (installed just moments before this writing), I created a model with a "name" field, then created a migration for it. Moments after, I added an "age" field to the model, deleted the 0001_initial.py migration, deleted __pycache__ directories in my entire project, deleted any *.py[cod] files in my project, then ran makemigrations again (the goal being to create a fresh 0001 migration with the latest fields again, since there is no SQLite3 database file (I verified this as well)). When I do this, Django creates the same 0001 migration it did the first time, then creates a 0002 migration to add the new field. Firstly, how is this even possible? Second, is this a known issue in 1.8? I've never experienced this bug before, and it's always been my M.O. on a new project to recreate a 0001 migration when I'm first working on the models (to avoid having 30 migrations before the app is even on a dev server).

[Curtis Maloney]

Could you provide details about what sort of field you added, please?

I have seen cases where migrations will create two separate migrations for an initial.

--

Curtis

On 9 February 2015 at 10:11, Yo-Yo Ma <baxters...@gmail.com> wrote:

Using Python 3.4.2 and Django @stable/1.8.x (installed just moments before this writing), I created a model with a "name" field, then created a migration for it. Moments after, I added an "age" field to the model, deleted the 0001_initial.py migration, deleted __pycache__ directories in my entire project, deleted any *.py[cod] files in my project, then ran makemigrations again (the goal being to create a fresh 0001 migration with the latest fields again, since there is no SQLite3 database file (I verified this as well)). When I do this, Django creates the same 0001 migration it did the first time, then creates a 0002 migration to add the new field. Firstly, how is this even possible? Second, is this a known issue in 1.8? I've never experienced this bug before, and it's always been my M.O. on a new project to recreate a 0001 migration when I'm first working on the models (to avoid having 30 migrations before the app is even on a dev server).

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/bfb1f2cd-b2be-4a16-a882-ecc6695865c9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Andrew Godwin]

Indeed, Django can make many migrations for an initial set if it needs them to de-circularise dependencies (e.g. two models with foreign keys pointing at each other - it splits one of their FKs into a second migration).

Andrew

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAG_XiSD%3DG4tR6fE4aF6xdgdEX6%3D0gRRCTW8%3DyiS8g9KBrBz7pA%40mail.gmail.com.

[Yo-Yo Ma]

Sorry for the belated reply, Andrew and Curtis.

You're both right that the "bug" was just a case of makemigrations resolving dependency issues and my misunderstanding of that fact.

To test whether this was a bug or just makemigrations splitting up the migration, I had created a separate app with the exact same model as the supposedly offending app, and this time it didn't result in 2 migrations, so I thought I had empirically proven that this was some sort of pycache related bug... Afterword, I realized that this was because I had created the dependency's 0001 migration first, which of course then allowed makemigrations to simply add that 0001 migration as a dependency.


Michael