See migration status:
python manage.py migrate --list
Create a working project with south. Then makemigrations and new compatible migration files are created in the new migrations folder.
Adding migrations to new apps is straightforward - they come preconfigured to accept migrations, and so just run makemigrations once you’ve made some changes.
If your app already has models and database tables, and doesn’t have migrations yet (for example, you created it against a previous Django version), you’ll need to convert it to use migrations; this is a simple process:
python manage.py makemigrations your_app_label
This will make a new initial migration for your app. Now, run python manage.py migrate –fake-initial, and Django will detect that you have an initial migration and that the tables it wants to create already exist, and will mark the migration as already applied. (Without the –fake-initial flag, the migrate command would error out because the tables it wants to create already exist.)
Note that this only works given two things:
You have not changed your models since you made their tables. For migrations to work, you must make the initial migration first and then make changes, as Django compares changes against migration files, not the database. You have not manually edited your database - Django won’t be able to detect that your database doesn’t match your models, you’ll just get errors when migrations try to modify those tables.
If you already have pre-existing migrations created with South, then the upgrade process to use django.db.migrations is quite simple:
Ensure all installs are fully up-to-date with their migrations. Remove 'south' from INSTALLED_APPS. Delete all your (numbered) migration files, but not the directory or __init__.py - make sure you remove the .pyc files too. Run python manage.py makemigrations. Django should see the empty migration directories and make new initial migrations in the new format. Run python manage.py migrate --fake-initial. Django will see that the tables for the initial migrations already exist and mark them as applied without running them. (Django won’t check that the table schema match your models, just that the right table names exist).
That’s it! The only complication is if you have a circular dependency loop of foreign keys; in this case, makemigrations might make more than one initial migration, and you’ll need to mark them all as applied using:
python manage.py migrate –fake yourappnamehere
http://stackoverflow.com/questions/29888046/django-1-8-create-initial-migrations-for-existing-schema
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):
Empty the django_migrations table: delete from django_migrations; For every app, delete its migrations folder: rm -rf <app>/migrations/ Reset the migrations for the "built-in" apps: python manage.py migrate --fake For each app run: python manage.py makemigrations <app>. Take care of dependencies (models with ForeignKey's should run after their parent model). 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.
So the basic process for using migrations looks like this:
That’s it! Pretty straight-forward for the basic use-case. Fortunately, this basic use case will work the majority of the time!
That’s all well and good if you’re starting from scratch but many people will be upgrading from a previous version of Django and migrating from South.
To do that, Django recommends to just start using the new migrations system and everything should work. The recommended upgrade path from South to Django 1.8 migrations, paraphrased from here is basically:
Delete all your South migration files (yup – just blow ‘em away). Run ./manage.py makemigrations. Django will just make initial migrations files based upon your current models. Run ./manage.py migrate. Django will see the tables that already exist for your migrations and just mark them as completed without running them.
Now, if you have circular dependencies and are getting errors when going through the above process, you may have to fake the migration with:
$ ./manage.py migrate --fake <appname>
Also, if you have a need to support both South and Django Migrations at the same time then upgrade to South 1.0 and read this article.
It’s also worth mentioning that if for whatever reason you want to see what migrations are in a certain app / project you can use the showmigrations command like so:
$ ./manage.py showmigrations --list
This will list all apps in the project and the migrations associated with each app. Also it will but a big X next to the migrations that have already been applied. Useful information if you’re trying to understand what migrations exists / have been applied to your project.
A similar scenario is when you already have a database (maybe because you have restored it from production) and you want to start working with migrations against that database without blowing away the data already there. In that case you can use the –fake-inital option:
$ ./manage.py migrate –fake-initial <appname>
This will look at your migration files, and basically skip the creation of tables that are already in your database. Do note though that any migrations that don’t create tables but rather modify existing tables will be run. This makes it simple to work with existing databases.