关于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的表,暂时不知道有什么用,倒也不影响使用,先放下了。

你可能感兴趣的:(遇过的坑,个人心得)