关于Django的contenttypes数据迁移

在使用Django开发过程中遇到一个问题，在使用了ContentType、GenericForeignKey、GenericRelation等模块时，如果要使用dumpdata迁移数据，你可能会发现，数据库中django_content_type这张表中模块的id会变化，导致数据乱掉！
后来发现，这个锅是没有按Django官方要求来操作导致的，一定要在项目代码里面保存migrations文件。

出现这个问题的原因：

1. 数据库中django_content_type这张表model的id是有固定顺序的：按照你settings.py中INSTALLED_APPS的顺序排，一个模块的models.py中有多个class，按你代码写的顺序从上到下排。
2. 如果你在某个models.py中新加了一个class，在你makemigrations -> migrate 之后，新的model的id就是最大的id+1
3. 但如果你没有保存migrations文件，部署时候是重新生成的migrations文件，那么新加的model的id就是按第1条中说的顺序排，这样会导致它之后的id全部加一，使用了ContentType的模块的数据自然就乱了

解决这个问题的方法也很简单，就是按Django官方文档说的：

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文件，如果你和我一样是嫌几个人开发的时候migrations会冲突而不想提交到git，那至少在要发布的分支中包含migrations文件

• 按照官方的说法，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.

• 如果你很不幸已经犯了和我同样的错误，没有在项目中保存migrations文件，并且项目的models有改动，你可以在迁移数据(dumpdata -> loaddata)的时候把之前的项目的migrations文件copy过去，再执行makemigrations

Django的Contenttypes，请参考官方文档
Django的migrations，参考官方文档