django 1.7 manage.py 详解

      django 自从 1.7 之后解决了很多问题，并且对于数据库的操作带来了几个新命令用以解决数据迁移问题，今天开始看看文档学习一下。部分内容来源于网络

Django 自 1.7 之后增加了类似 South 的 migration 功能，修改 Model 后可以在不影响现有数据的前提下重建表结构。这真是个千呼万唤始出来的 feature 了

一、migration 介绍

Migrations 其实就是一堆帮助你完成数据库变更和数据迁移的命令，使得你可以用 “Django” 的方式来管理和变更数据库的 schema。

1.1 特性

Migrations让事情变得简单可控：

• 它使得数据库 schema 的调整可以通过Django命令来完成
• 它使得数据库的 schema 和对应的 model 的变更被 track 起来：整个历史都可以版本化在 Git 里面
• 提供了一套匹配 schema 和对应的 fixture 的机制
• 如何和 CI 搭配起来，可以保证代码和数据一致性

1.2 创建 migrations

当有新的 models 创建或者变更的情况下，需要创建一个 migration

1	# python manage.py makemigrations <appname> Migrations for 'fault_reports': 0001_initial.py: - Create model FaultReports - Create model Log - Create model User

• 执行完并生成个文件：<appname>/migrations/0001_initial.py
• 文件是一个夹杂着 mysql 语句的 python 文件，可以手动修改

查看建表语句

1	python manage.py sqlmigrate <appname> 0001

 

这里有个注意的问题是那个 0001，其实是 app_lable，默认创建的时候为 0001，可以在 migrations 的目录下看到文件的前缀，其实就是 app_lable

检查所有的配置是否OK

1	python manage.py check

 

1.3 应用 migrations

创建对数据库修改及新建。只对新增的内容操作，这样以后有改动就不用删除数据库或表了

1

# python manage.py migrate (django182-py2710)➜ ops git:(develop) ✗ ./manage.py migrate Operations to perform: Synchronize unmigrated apps: staticfiles, messages Apply all migrations: admin, fault_reports, contenttypes, auth, sessions Synchronizing apps without migrations: Creating tables... Running deferred SQL... Installing custom SQL... Running migrations: Rendering model states... DONE Applying contenttypes.0001_initial... OK Applying auth.0001_initial... OK Applying admin.0001_initial... OK Applying contenttypes.0002_remove_content_type_name... OK Applying auth.0002_alter_permission_name_max_length... OK Applying auth.0003_alter_user_email_max_length... OK Applying auth.0004_alter_user_username_opts... OK Applying auth.0005_alter_user_last_login_null... OK Applying auth.0006_require_contenttypes_0002... OK Applying fault_reports.0001_initial... OK Applying sessions.0001_initial... OK

如果是全新的 app，这两步已经结束了，不需要 syncdb 操作了。总结一下。流程如下

• 1、建立或者更新一个 model
• 2、运行 python manage.py makemigrations <app_name>
• 3、运行 python mange.py migrate <app_name> 来应用创建的 Migrations
• 4、重复前面的步骤

1.4 已有项目进行 migration

日后项目的过程中可能会修改 models 结构，那么就需要如下操作

• 1、运行 ./manage.py makemigrations <appname>，Django 会根据你当前 model 来创建那份 initial migrations file。
• 2、运行 ./manage.py migrate，Django 会把已经存在的数据库 table 当成是 makemigration 的产物，完成整个 migration

如果运行报错了，那么就需要做一个并不是真 migration 的 fake 了。

1	./manage.py migrate --fake <appname> - Mark migrations as run without actually running them

 

1.5 更多细节

如果你再次运行 python manage.py migrate，会发现什么都没有发生：这是因为在项目的数据库中有一张 django_migrations 仍然被更新。表，记录了哪些 Migrations 已经被应用过了：无论是运行了 migrate 还是 fake 的，这个表都会被插入一条记录。比如从 South 升级到使用 Django 自带的MigrationsDjango 会检查是否有更新。如果没有，它就 fake 一次，但 django_migrations 仍然被更新。

在少数情况下，确实有需要再次运行某个特定的 Migrations，我们可以在 django_migrations 里面把这个记录删除掉。

在极少数情况下，如果你有需要回退到特定的版本，比如最初的 zero 版本，可以用类似

1	python manage.py migrate <app_name> zero

 

  

参考阅读

• django-admin and manage.py
• Django 1.7 自带 migrations 用法及源码
• Django 模型修改及数据迁移
• Data Migration in Django 1.7 (1)
• Data Migration in Django 1.7 (2)
• 转自： http://mingmings.org/note/2015/07/07/django-1-7-manage-py-%E8%AF%A6%E8%A7%A3.html