Django 1.8: Create initial migrations for existing schema

Solution 1:

Finally got it to work, although I don't know why and I hope it will work in the future.
After doing numerous trials and going through Django's dev site (link).
Here are the steps (for whoever runs into this problem):

1. Empty the django_migrations table: delete from django_migrations;
2. For every app, delete its migrations folder: rm -rf <app>/migrations/
3. Reset the migrations for the "built-in" apps: python manage.py migrate --fake
4. For each app run: python manage.py makemigrations <app>. Take care of dependencies (models with ForeignKey's should run after their parent model).
5. Finally: python manage.py migrate --fake-initial

After that I ran the last command without the --fake-initial flag, just to make sure.

Now everything works and I can use the migrations system normally.

I'm sure I'm not the only one who encounters this issue. It must be documented better and even simplified.

Update for Django 1.9 users:
I had this scenario again with a Django 1.9.4, and step 5 failed.
All I had to do is replace --fake-initial with --fake to make it work.

Solution 2:

django ..., 1.8, 1.9, ...

What you want to achieve is squashing existing migrations and use replacement for them.

How to do it right without using any command when releasing (a case without impact on database and coworkers).

1. For every app, get rid of its migrations folder: mv <app>/migrations/ <app>/migrationsOLD/

2. For each that app run: python manage.py makemigrations <app>.

3. Customize each new migration:

   • if you have a complex app, or more apps and related models between them, to avoid CircularDependencyError or ValueError: Unhandled pending operations for models:

     prepare second empty migration in <app> 0002_initial2.py (put there dependency to app_other::0001_initial.py and <app>::0001_initial.py as well - all ForeignKey, M2M related to models created in 0001 migration step in other apps)

     All must be in order - sometimes it will require more migrations to prepare. Take care of dependencies attribute here in each Migration.

   • take care of initial values - verify yourself all RunPython actions from migrationsOLD and copy the code to new initial migration if needed.

   • (optional for --fake-initial) Add initial=True to all new Migration classes (0002 too if was added).

   • Add replaces attribute in new Migration class. (like own custom a squashmigrations). Put there all old migrations from <app>

4. Verify everything with makemigrations.

   assert "No changes detected"

5. Check if migrate -l show [x] everywhere

   assert similar:

   [X] 0001_initial

   [X] 0002_initial2 (102 squashed migrations)

Example:

For old:

0001_initial.py
0002_auto.py
...
0103_auto.py

prepare:

0001_initial.py
0002_initial2.py  (optional but sometimes required to satisfy dependency)

and add to replacesto last one (0002 here, can be 0001):

replaces = [(b'<app>', '0002_auto.py'), ..., (b'<app>', '0103_auto.py')]

0001_initial.py should be named the same way as old one.

0002_initial2.py is new one, but it's a replacement for old migrations so Django will treat it as loaded.

Solution 3:

I've run into this scenario but I've never had to drop the database to solve it. Typically I delete the migrations folder from the app's, and remove the migration entries from the database.

I would try to run make migrations one app at a time. If any of the app's rely upon other tables obviously add them last.

Also I usually just run, python manage.py makemigrations then just python manage.py migrate Even with the initial migration it should work fine with Django 1.7 and 1.8.