小谈django数据库迁移

本篇文章将从数据库迁移的原理出发，详细谈一谈在进行数据库迁移过程中的问题。

django框架就是一款强大的ORM框架，可以不需要写sql语句就能进行应用开发。 ————官方说明文档

一、

首先，简短说一下数据库迁移。说白了，其实就是将数据库中的数据导出为sql语句来进行sql操作。而对于django而言，强大之处就在于在通过迁移命令执行数据库迁移后，生成迁移sql语句脚本进行相应的数据库操作。
在数据库迁移之前，我们首先要生成迁移文件，命令耳熟能详

python manage.py makemigrations

或者单独对某一模块进行迁移操作

python manage.py makemigrations [模块名]

这样就生成了迁移文件，在相对应的项目应用中可以看到migrations文件夹下，生成一个新的以数字打头的迁移文件。
而下一步就是执行迁移操作了

python manage.py migrate

或者单独迁移某一模块

python manage.py migrate [模块名]

迁移过之后，我们会发现在数据库中多了迁移模型的数据表，查看相应表也可以看到我们所建立的字段和类型。
但也多了几张表,其中一张便是django_migrations,这张表即是记录我们在每次执行迁移操作时记录的迁移文件的数据表。具体记录的是模块和与其对应的迁移文件名。

二、

在我们协同开发过程中，遇到模型复用和更新迭代是最常见的事情，有时候我们会多次数据库迁移来对旧表进行修改。但随着迭代版本的增加太多的迁移文件有时却让自己很烦，在版本控制时也会产生一些冲突和意想不到的bug。那么有时候就需要重新迁移文件，所以在删除迁移文件migrations的同时还要清楚django_migrations表里的记录。来再次重新迁移。
那么通过这一点规律来做一点小事情。
有时候，在版本控制的时候，每个人的操作习惯不太相同，有些开发者喜欢不提交迁移文件，而在服务器拉下代码后进行迁移操作。但当项目上线之前跑量的过程中却清除了数据库中的数据，再次提交migrate操作时就会出现迁移数据表已经存在的错误信息。（当然，这并不影响服务器的运行，也不会有任何异常，只是一直会有个报错而已罢了），对于我这样的强迫症是不能忍的，干掉错误信息！一张两张表可能我们会选择删除表之后重新迁移，但是如果模型过多删除表的操作也相应增多（况且，有一些表的数据我还不想全部删除）。

错误信息.jpg

那么，其实在清空表数据的同时备份django_migrations为sql文件是非常有必要的了。

三、

究竟该不该提交migrations？
官方文档对于这个问题是这么解释的

You should think of migrations as a version control system for your database schema. makemigrations is responsible for packaging up your model changes into individual migration files - analogous to commits - and migrate is responsible for applying those to your database.
The migration files for each app live in a “migrations” directory inside of that app, and are designed to be committed to, and distributed as part of, its codebase. You should be making them once on your development machine and then running the same migrations on your colleagues’ machines, your staging machines, and eventually your production machines.

中文翻译

你可以想象 migrations 相当一个你的数据库的一个版本控制系统。makemigrations 命令负责保存你的模型变化到一个迁移文件 - 和 commits 很类似 - 同时 migrate负责将改变提交到数据库。
每个 app 的迁移文件会保存到每个相应 app 的“migrations”文件夹里面,并且准备如何去执行它, 作为一个分布式代码库。 每当在你的开发机器或是你同事的机器并且最终在你的生产机器上运行同样的迁移，你应当再创建这些文件。

其实无非是集中情况而已罢了

情况一： 开发环境和生产环境使用同一数据库，
那么完全不用考虑这个问题，只要对django_migrations表进行备份，不要误删就好了。在提交代码时提交迁移文件，在服务器上也不用执行相应的迁移操作了。
情况二： 开发环境和生产环境使用不同数据库，
那么这个问题其实也很好解决，提交迁移文件之后直接在服务器进行迁移操作。或者不提交在服务器上自主生成迁移文件，再进行迁移操作。那么在随着版本迭代的过程中，开发环境的迁移文件也许会比生产环境的迁移文件多得多，那么就产生了也许在不同开发者的开发设备中版本不统一问题。再加上每人操作习惯不同，不提交迁移文件就会产生在服务器端重新迁移，对于日后的版本控制相当不友好。
所以，其实对于迁移文件也是应该直接提交至远程仓库的。