Django下一个版本是1.7，增加了类似South的migration功能，修改Model后可以在不影响现有数据的前提下重建表结构。这真是个千呼万唤始出来的feature了，所以做个简单的整理分享。文章包含部分源代码，对具体怎么实现不感兴趣可以忽略。
Prepare
从Django官网或直接pip下载1.7b版本，创建project和app：
$ pip install https://www.djangoproject.com/download/1.7b2/tarball/
$ python manage.py startproject dmyz
$ cd dmyz/
$ python manage.py startapp articles
修改articles/modules.py文件，增加Article，accounts到dmyz/settings.py文件的INSTALLED_APPS，以下是对这两个文件的修改：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
# ===== articles/modules.py ===== # encoding: utf8 from django models from django User class Article title = models null # ===== dmyz/settings.py ===== INSTALLED_APPS = ( ‘django.contrib.admin‘ ‘django.contrib.auth‘ ‘django.contrib.contenttypes‘ ‘django.contrib.sessions‘ ‘django.contrib.messages‘ ‘django.contrib.staticfiles‘ ‘articles‘ ) |
在dmyz/settings.py文件中调整数据库设置。按照官方文档的说明，支持得最好的是postgresql数据库，其次是mysql，目前sqlite不能实现完整的migration功能。本文是在64位Window+Cgywin环境下写的，使用的是mysql5.6版。设置完成后执行syncdb（不执行syncdb也不影响执行makemigrations创建migration文件的操作）命令创建数据库。
makemigrations
首先要创建migrations，新版Django执行manager.py startapp会生成migrations/目录，makemigrations命令生成的文件会存到migrations/目录下。
$ python manage.py makemigrations articles
Migrations for ‘articles’:
0001_initial.py:
- Create model Article
$ ls articles/migrations/
__init__.py 0001_initial.py
创建migrations/文件夹，写入__init__.py文件和migration文件使用的是以下代码：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
# django/core/management/commands/makemigrations.py writer = MigrationWriter if self >= 1 self % ( for operation migration self % operation # 如果增加 --dry-run参数就不写入migration文件，只显示描述结果 if not self migrations_directory = os.path if not directory_created False if not os.path os init_path = os.path "__init__.py" if not os.path open "w" # We just do this once per app directory_created = True migration_string = writer with open "wb" as fh fh |
检测app目录下是否存在migrations/目录，不存在就新建，再以write的方式操作__init__.py文件，最后把生成的migration代码写到文件中。
MigrationWriter(Line 1)在writer.py文件中定义。Python代码用缩进来划分逻辑，下面这段代码用了三个方法(indent/unindent/feed)，调用indent/unindent时给self.indentation增/减1，需要缩进时调用feed方法补上对应的空格实现缩进：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 |
# django/db/migrations/writer.py imports = set for arg_name argspec arg_value = normalized_kwargs if ( self isinstance ( tuple dict if isinstance dict self % arg_name self for key value arg_value arg_string arg_imports = MigrationWriter self % ( arg_string imports self self else self % arg_name self for item arg_value arg_string arg_imports = MigrationWriter self % arg_string imports self self else arg_string arg_imports = MigrationWriter self % ( arg_string imports self self return self imports def indent self += 1 def unindent self -= 1 def feed line self * ( * 4 + line def render return ‘\n‘ |
接下来修改articles/models.py，增加一个field，再次执行makemigrations：
|
1 2 3 4 |
# articles/modules.py class Article title = models null author = models null |
$ python manage.py makemigrations articles
Migrations for ‘articles’:
0002_article_author.py:
- Add field author to article
自动检测新旧两个modle的差异是一个相当麻烦的工作，autodatector.py的代码比其他文件都长，但逻辑是很清晰的。主要是从上一个migration中获取之前的Model列表，写到set中，现有Model也是同样能够的操作，遍历这两个set的差集，获取差集Model中所有的field，如果field的定义相同，就询问用户是否是一个rename的model，否则视为创建。
autodatectory.py在测试的过程中raise了几个错误，代码量也不少，所以只附上源代码链接，不贴在原文里了：
https://raw.githubusercontent.com/django/django/stable/1.7.x/django/db/migrations/autodetector.py
migrate
之前的两次makemigrations操作只是生成migration文件，还没有对数据库进行操作，接下来执行migrate命令：
$ python manage.py migrate articles
Operations to perform:
Apply all migrations: articles
Running migrations:
Applying articles.0001_initial FAKED
Applying articles.0002_article_author OK
执行后数据库articles_article这张表会增加author_id字段，执行过的migration文件会记录到django_migrations表中，避免重复执行。带--fake参数执行migrate命令时，只将migration文件记录到数据库的django_migrations表，如果是用South的migration文件，fake操作就很关键了。
这是migration操作中处理数据库的部分，主要代码都在django/db/migrations/operations/目录下，拆分成4个文件：base.py fields.py models.py special.py，和文件名表达的含义一样，文件中是针对Model/Field做Create/Rename/Delete的操作，调用这些文件是从djangp/db/migrations/migration.py文件开始的：
|
1 2 3 4 5 6 |
for operation self new_state = project_state operation new_state operation schema_editor project_state new_state project_state = new_state return project_state |
在Line 4调用了database_forwards方法，传入的第一个参数是app名称，最后两个参数原state和新的state，里面包含所有字段的定义。schema_editor是根据数据库指定的DatabaseSchemaEditor类，
之后的操作就是各种调用了：调用opration的方法，oprations调用根据具体的操作(add/alter/remove)调用db/backends/数据库类型/schema.py的方法，真正实现对数据库的操作，主要代码如下：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
def database_forwards app_label schema_editor from_state to_state old_apps = from_state new_apps = to_state old_model = old_apps self new_model = new_apps self if router new_model schema_editor new_model old_model new_model ) def alter_db_table model old_db_table new_db_table self % { "old_table" self "new_table" self } |
Afterword
这篇文章在草稿箱里存了半年（2013年11月）了，因为花了不少的时间看源码，以及等bug修复，现在的beta2版本修复了之前M2M字段的问题，但autodetector仍然有bug(已经提交到Trac)。
South常年居于最受欢迎的Django应用列表，说明依据Model修改关系数据库结构是开发中的一个重要的问题，解决这个问题可以提升开发速度。当然也只是[开发]速度，关系数据库经常用来存储Web业务的核心数据，是Web应用最常见的性能瓶颈，South这种用了好几年的模块也不敢在生产环境数据库上随便操作，更不用说现在还有Bug的自带migration了。
什么时候关系数据库也能完美的实现freeschema，开发就更美好了:)