django orm原理_Django migration 原理

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

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

参与 Class 和 Table 结构一致的，一共有3个角色：

Models：只记录了现在的 Model 是什么样子的；

Migrations：记录了 Model 是如何从最初的样子，变成现在这个样子的——即要变成现在的样子，需要走哪几步；

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

一次 migration 之旅

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

从一个用户的角度看，我们做一次 migration，只需要3步：

修改 models.py，比如添加字段；

执行 python manage.py makemigrations ；

执行 python manage.py migrate ；

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

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

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

所以首先，Django 要知道你的 Model 做了哪些变化