关于django makemigrations/migrate在生成数据表上遇到的一些问题

由于公司以前的项目采用的是通过sql文件迁移数据库的方法，虽然在后续接手工作的时候没什么不适，但是对于一个全新的项目来说，要重新手动生成数据库表实在太花时间了，还容易导致model与表结构不一致，故此特意认真学习使用migrate这个功能。

问题一：makemigrations并migrate后，发现有的model并没有生成数据表。重新makemigrations却提示No changes detected。

原因：

在对比了几个model在migrations上的区别以后发现

class Sys(models.Model):
    id = models.CharField(max_length=255, primary_key=True, unique=True)

    class Meta:
        managed = False
        db_table = 'sys'

问题出在"managed = False"上，由于按照以往项目的习惯，直接抄了下来，原来是不生成数据表的意思，去掉就好了。

问题二：手动把数据库的表删除后再migrate却提示 No migrations to apply.

原因：数据库里还有一个django-migrate表，把里面的相关数据也一并删了就可以了。

问题三：在设置了AUTH_USER_MODEL后产生的一系列奇怪的问题。

像是诸如明明已经在INSTALLED_APP里添加了app的名字后，并确认已经导入的情况下，仍然提示

ValueError: The field admin.LogEntry.user was declared with a lazy reference to 'system.sysuser', but app 'system' isn't installed.

以及一些别的情况（忘了。。。）

解决方法：找到自己的/python3X/lib/site-packages/django/contrib/admin/migrations文件夹，把里面除了__init__.py的所有文件，全部删了再migrate就可以了。（注意，切勿把__init__.py文件删了，也不要把contrib/contenttypes这个文件夹下的migrations删了，不然会导致migrate功能失效，像我就只能把django卸了重下）

我自己想了一下，可能是因为在设置自定义用户模型之前，django已经默认了原来的user模型，导致后来再生成user表的时候冲突，不得不说，django把user模型的migrations文件放在自己的库里实在是太隐蔽了。

自此，migrate功能使用基本正常，另外还配套生成了一堆auth_xx的表，暂时不知道有什么用，倒也不影响使用，先放下了。