djangoorm原理_Djangomigration原理

Django 自带了一套 ORM&＃xff0c;就是将数据库的表映射成 Python 的 Class&＃xff0c;这样我们在写程序的时候&＃xff0c;就基本不需要写 SQL 和数据库交互了&＃xff0c;直接操作 Python 对象就可以了&＃xff0c;Django 的 ORM 把我们对类的操作&＃xff0c;转换成对数据库的 SQL 操作。

那么 Class 的属性是如何对应到 Table 的 Column 的呢&＃xff1f;Class 的属性变了&＃xff0c;如何关联到表结构的变化&＃xff1f;本文就介绍这种 migration 实现的原理。

参与 Class 和 Table 结构一致的&＃xff0c;一共有3个角色&＃xff1a;

Models&＃xff1a;只记录了现在的 Model 是什么样子的&＃xff1b;

Migrations&＃xff1a;记录了 Model 是如何从最初的样子&＃xff0c;变成现在这个样子的——即要变成现在的样子&＃xff0c;需要走哪几步&＃xff1b;

数据库中的 django_migrations 表&＃xff1a;记录在 Migrations 的所有步骤中&＃xff0c;当前的 Table 已经执行了哪几步&＃xff0c;这样就可以只执行没有执行过的步骤&＃xff0c;来变成最新的状态&＃xff1b;

一次 migration 之旅

前面我们说过&＃xff0c;Django ORM 基本屏蔽了用户需要做的 SQL 操作&＃xff0c;包括 DDL 操作。

从一个用户的角度看&＃xff0c;我们做一次 migration&＃xff0c;只需要3步&＃xff1a;

修改 models.py&＃xff0c;比如添加字段&＃xff1b;

执行 python manage.py makemigrations &＃xff1b;

执行 python manage.py migrate &＃xff1b;

这时候&＃xff0c;数据库中的 Table 和我们 Django 中的 Model 就对上了&＃xff0c;我们写业务逻辑就可以了。

但实际上&＃xff0c;Django 在背后做了什么呢&＃xff1f;如果不了解这些&＃xff0c;遇到一些问题就束手无策了(文末会提到一些经典的问题)。

在整个流程中&＃xff0c;Django 负责的是自动识别出 Model 进行了哪些变化&＃xff0c;将这些变化应用到 Table 中&＃xff0c;保证最终 Model 和 Table 还是对应的。本质上&＃xff0c;就是将 py 文件的变化&＃xff0c;转成数据库的 DDL 变化。

所以首先&＃xff0c;Django 要知道你的 Model 做了哪些变化。这是第2步&＃xff1a;生成 migrations。Migrations 生成的方式&＃xff0c;颇有点现在“声明式”的意思。

它的过程是这样的(这里我们将修改后的 Model 记作 Model-2&＃xff0c;修改前的 Model 记作 Model-1)&＃xff1a;从 migrations/ 文件夹下的 0001_xxx.py 开始 apply&＃xff0c;到 0002_xxx.py&＃xff0c;一直到最后一个文件&＃xff0c;这些文件都记录了 Model 的变化&＃xff0c;都 apply 一遍之后&＃xff0c;就得到了修改前的的 Model-1 的状态&＃xff0c;然后和修改过的 Model-2 来比较&＃xff0c;得到了 diff&＃xff0c;然后看如何消除这些 diff——即产生最新的 migrations 文件&＃xff0c;将 Model-1 的状态转移到 Model-2.这样新的 migrations 就生成了&＃xff0c;如果你再跑一遍的话&＃xff0c;就发现什么 migrations 也不会出现&＃xff0c;因为 migrations 文件记录的变化已经和最新的 Model 一样了(声明式天生的幂等性&＃xff01;)。

这些 migrations 记录了 Model 从 0001_init 开始的所有变化&＃xff0c;有了 migrations 文件&＃xff0c;你就可以从一个空的数据库&＃xff0c;变成现在的结构了。

但是如果数据库不是空的&＃xff0c;而是已经有一些结构呢&＃xff1f;通常是这种情况&＃xff1a;生产环境的数据库&＃xff0c;表结构是 v3(执行过migrations 0001,0002,0003)&＃xff0c;你在开发的时候生成了 migrations 0004,0005。那么怎么知道这个数据库只要执行 0004&＃xff0c;0005 就可以了呢&＃xff1f;更复杂一点的话&＃xff0c;假如你有一个灰度服务器&＃xff0c;一个生产服务器&＃xff0c;灰度服务器执行过了 0001-0004&＃xff0c;生产服务器落后一个版本&＃xff0c;执行了0001-0003&＃xff0c;怎么知道这些数据库应该执行哪些 migrations 呢&＃xff1f;

这里根本的问题是&＃xff1a;migrate 的执行(DDL的执行)不是幂等的。所以我们就需要一个地方&＃xff0c;记录一下哪些 migrations 已经被执行过了。Django 会自动在你的数据库中建立一张 django_migrations 表&＃xff0c;用来记录执行过的 migrations。这样你在执行 python manage.py migrate 的时候&＃xff0c;django 会去对比 django_migrations 表&＃xff0c;只执行没有执行过的 migrations&＃xff0c;无论你有多少表结构版本不同的数据库都没有关系。

下面再用一张图来表示一下整个过程。其实想明白了很简单(我也不知道为啥这张图画出来咋这么复杂&＃xff0c;点开可以看大图)。这张图是给一个很简单的 User Model 增加了一个字段。注意一开始蓝色的 Model 和 Table 是 map 的&＃xff0c;最终状态红色的 Model 和 Table 也是 map 的。

一些骚操作

有了上面的知识&＃xff0c;我们处理起来一些问题就得心应手啦&＃xff01;

1.migrate执行到一半失败了怎么办&＃xff1f;

这种情况是很容易发生的&＃xff0c;因为 make migrations 的时候&＃xff0c;Django 只知道消除 diff&＃xff0c;并不知道表结构。这就很有可能导致生成的 migrations 实际上是违反数据库约束的&＃xff0c;而不能执行成功。

最糟糕的情况是&＃xff0c;一个 migrations 中有很多步&＃xff0c;其中部分执行成功了。就造成数据库的结构处于一个“未知”的状态。

不过不要慌&＃xff0c;只要从 log 中看下哪些 migrations 步骤已经执行了&＃xff0c;去手动 revert&＃xff0c;然后从 django_migrations 删除这些记录即可。参考这篇文章。

2.migrations应不应该加入到 git 仓库中&＃xff1f;

应该&＃xff01;虽然是生成的代码&＃xff0c;但是也是要用版本管理&＃xff0c;让所有的数据库都执行一套 migrations&＃xff01;看看我的教训吧。

3.我什么 models 都没改&＃xff0c;但是每次 make migrations 都会生成新的&＃xff1f;

不要慌&＃xff0c;我也遇到过。这时候你去看下生成的 migrations 做了啥操作&＃xff0c;再想想 Django 为什么会这样做即可。

举个例子吧&＃xff0c;我之前的 models 里面一个 default 值用了字典&＃xff0c;我们知道字典 key 是没有顺序的(Python 3.7)之前&＃xff0c;就导致每次 make migrations 的时候&＃xff0c;顺序都有几率不一样&＃xff0c;Django 就认为状态不一致&＃xff0c;需要新的 migration 文件来消除 diff。

4.migrations 文件冲突了&＃xff0c;我和同事开发的时候&＃xff0c;我生成了一个 0003_xxx.py 我同事也生成了这个 0003.

不要慌&＃xff0c;这是正常现象。按照 Django 的提示&＃xff0c;执行生成一个新的 migrations 来 merge 前面的两个就好啦。python manage.py makemigrations --merge 。

5.我的migrations太多了&＃xff0c;每次 makemigrations 都要等很久&＃xff0c;或者我的 migrations 文件名已经快到 999_xxx.py 了&＃xff01;

我一生中只遇到过一个这样的项目。解决方法也很简单&＃xff0c;因为我们只需要一个最终的状态&＃xff0c;所以我们可以将之前的 migrations 都删掉。

步骤如下&＃xff1a;

备份整个项目和数据库(非常重要)&＃xff1b;

删除除了 __init__.py 之外的所有 migrations 文件夹下的文件&＃xff1a;ls */migrations/*.py | grep -v __init__ | xargs rm;

重新生成 migrations 文件&＃xff0c;不出意外的话&＃xff0c;所有的 app 都只有一个 migration 文件&＃xff0c;就是 init&＃xff1b;

删除数据库 django_migrations 表中所有的记录&＃xff1a;delete from django_migrations&＃xff1b;

因为我们的表结构已经是最新的了&＃xff0c;所以新生成的 init migrations 并不需要执行。所以我们插入记录到 django_migrations 中&＃xff0c;骗 djagno 我们已经执行过了。用这个命令&＃xff1a;python manage.py migrate --fake&＃xff1b;

大功告成&＃xff0c;不出意外&＃xff0c;makemigrations 又快了起来。

其他的一些骚操作

如何查看一个 migration 文件对应的 SQL 是啥&＃xff1f;

1

2

3

4

5

6

7

$pythonmanage.pysqlmigrateusers0001

BEGIN;

--

--CreatemodelUsers

--

CREATETABLE"users_users"("id"integerNOTNULLPRIMARYKEYAUTOINCREMENT,"name"varchar(33)NOTNULL,"age"integerNOTNULL,"gender"varchar(8)NULL);

COMMIT;

如何查看这个数据库执行过哪些migrations了&＃xff1f;

1

2

3

4

5

6

$pythonmanage.pyshowmigrationsusers

users

[X]0001_initial

[X]0002_auto_20190803_1549

[]0003_auto_20190803_1550

[]0004_auto_20190803_1550

最后 n 次执行的 migrations 有问题&＃xff0c;数据库炸了&＃xff0c;要不要删库跑路&＃xff1f;

不用。

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

➜pythonmanage.pymigrate

Operationstoperform:

Applyallmigrations:admin,auth,contenttypes,sessions,users

Runningmigrations:

Applyingusers.0003_auto_20190803_1550...OK

Applyingusers.0004_auto_20190803_1550...OK

➜pythonmanage.pymigrateusers0002

Operationstoperform:

Targetspecificmigration:0002_auto_20190803_1549,fromusers

Runningmigrations:

Renderingmodelstates...DONE

Unapplyingusers.0004_auto_20190803_1550...OK

Unapplyingusers.0003_auto_20190803_1550...OK

➜pythonmanage.pyshowmigrationsusers

users

[X]0001_initial

[X]0002_auto_20190803_1549

[]0003_auto_20190803_1550

[]0004_auto_20190803_1550

其他一些类似 Django ORM 的 migrations 的项目&＃xff1a;