Why Django 1.7 move from syncdb to migrate?

Question

I am trying to understand the difference between syncdb and migrate on Django 1.7, I have read some stack post about the difference. I get that it depends on the version, that the next version of Django will implement "migration" and that for now, South is an external app, etc.

But what is the difference beyond the scene, I mean technically speaking? What does migrate do differently?

Answer 1

I agree with Maxime: Check out Andrew Goodwin's talk - Designing Django's Migrations. It's a great place to start.

We've also put together a series on Django migrations:

1. Part 1: Django Migrations - A Primer
2. Part 2: Digging Deeper into Migrations
3. Part 3: Data Migrations
4. Video: Django 1.7 Migrations - primer

Take a look at the first article to see the differences between syncdb and migrate, while the second article details everything that happens behind the scenes.

Answer 2

From Django 1.7, the framework implements a built-in migration system. As you said, there is already South for that but it was an external module. When you were using Django in the past and you modified a model already created in database, you had to make alter the table "by hand" if you didn't use South. syncdb was only creating the table the first table and could not update it when the model was changed.

The 1.7 release notes says:

Django now has built-in support for schema migrations. It allows models to be updated, changed, and deleted by creating migration files that represent the model changes and which can be run on any development, staging or production database.

This means that when you are adding, modifying or deleting a field in a model, you can create a Python file which will applies these changes to your database. This is handy since every developer can now update their local version or the production in one simple command: manage.py migrate.

Thanks to this system, you have less errors since you do not need to report models modifications in the database by yourself, it is easier to keep an history and work with a VCS (you can go forward and backwards with migrations, or undo/redo migrations if you prefer). Indeed, these Python files created are stored in the folder <app>/migrations and there is one file per modification.

It has been integrated to Django because everyone needs it and it doesn't cost you anything to have it (runtime performance are not affected). If you want to know more about this subject, I recommend you this talk: Andrew Godwin: Designing Django's Migrations - PyCon 2014 (Youtube video - 26min)