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

# 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 文件,可以手动修改

查看建表语句

python manage.py sqlmigrate <appname> 0001

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

检查所有的配置是否OK

python manage.py check

1.3 应用 migrations

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

# 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 了。

./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 版本,可以用类似

python manage.py migrate <app_name> zero

  

参考阅读