Django中的模型与迁移
根据Django的MVC架构特性,一般而言我们在本地开发时,当涉及到数据模型,步骤如下:
- 配置数据库信息;
- 定义/修改模型类(一个模型类对应数据库中的一张表)
当我们定义好模型时,数据库中并没有表,接下来我们需要进行迁移; - 执行命令,生成对应的迁移文件;
- 执行迁移,生成/修改对应的数据表;
可以看到,在命令的执行层面分成两步:
第一步,执行makemigrations
命令,我们可以简单理解为记录当前app的模型变化信息;
第二步,执行migrate
命令,这里我们可以简单理解为将对应的迁移文件解析成SQL并直接到连接的数据库中执行;
通过这套步骤,Django可以很方便的进行模块数据模型的变化记录、修改数据库信息。
云服务背景下的不同之处
在本地环境中,上述步骤是很自然、没有问题的,但是来到云服务的环境中就有一些问题:服务使用的是RDS,有着严格的权限管控,所有的SQL执行均需要通过运维系统提交、检测、审批,这样Django的migrate
命令就无法执行了。
此时,我们在第二步需要改用sqlmigrate
命令:这个命令并不会直接去执行SQL,而是根据对应的迁移文件生成对应的SQL命令,在获取到这样的命令后,我们再到对应的IT平台提交执行即可。
不过,这里又有一个问题。
Django的模型迁移、SQL执行与服务启动是按顺序一气呵成的,中间并没有什么断点。
但是到云服务场景下就不同了:服务的升级部署、SQL的执行是分开的,这就造成如果服务服务先行升级部署,但SQL未执行,或者SQL先执行但服务未升级部署仍使用老模型与迁移文件,都有可能造成问题,当然,这也需要分开进行讨论。
1、新增表
对于这类,新增的数据表并不会对已有的部署代码造成什么困扰,因此可以在新代码部署之前就执行SQL。
2、新增字段
新增字段类似于新增表,但是也有不同之处:
- 如果新增的字段是有默认值、并且支持为空的,那么在新代码部署之前,老代码在新增数据时数据库会自动给新字段赋值,因此也不会造成什么影响。
- 如果新增的字段并没有默认值,也不许为空,那么老代码如果创建数据时,数据库层面自然就会报错了,因此这时我们需要等到服务部署完成之后才能执行SQL。
3、修改/删除字段
这种情况就没啥好讨论的了,为了避免出现问题,SQL要在部署完成后执行,并且二者时间间隔尽量的短。