Django数据库迁移命令!报错django.db.utils.OperationalError: (1091, ...)?迁移版本报错解决 ✧*。٩(ˊᗜˋ*)و✧*。 Django初体验
文章目录迁移命令makemigrations(生成迁移脚本)makemigrations参数migrate(将迁移脚本映射进入数据库)migrate参数showmigrations(查看迁移文件)sqlmigrate(迁移使用SQL)migrations中的迁移版本常见报错django.db.utils.OperationalError: (1091, "Can't DROP '***'; che
文章目录
发生django.db.utils.OperationalError或其他因为不小心删除了migration或者数据库中记录的映射引起的报错可以直接查看 migrations中的迁移版本常见报错
迁移命令
执行迁移命令必须确保你当前在项目目录下(执行ls
命令能看到manage.py文件),然后使用python manage.py 迁移命令
即可。如果IDE为pycharm你也可以在运行/调试配置中创建命令,下方我所有迁移命令均在pycharm中完成。
makemigrations(生成迁移脚本)
makemigrations是我们多次使用的命令,他会将我们model.py中创建的数据库模型生成迁移脚本库,每次只要我们的数据库模型model.py
中发生了变化,使用python manage.py makemigrations
就会在migrations中创建一个记录我们变化的脚本
makemigrations参数
默认不带参数的情况下,makemigrations会迁移当前项目中所有APP中的模型,并且生成迁移脚本,并且迁移脚本库名当修改较少时会根据修改内容生成名称,但在数据库做过多修改时会生成一个为当前时间的名称。
makemigrations参数 | 作用 |
---|---|
APP名称 | 可以填写一个或者多个app名称,那么就只会针对这几个app生成迁移脚本。 |
--name 名称 | 给这个迁移脚本指定一个名字。 |
--empty | 生成一个空的迁移脚本。如果你想写自己的迁移脚本,可以使用这个命令来实现一个空的文件, |
比如我下面写到python manage.py makemigrations query --name add_VIP
可以直针对query APP生成迁移脚本,并且脚本名称为add_VIP
migrate(将迁移脚本映射进入数据库)
migrate也是非常常用的命令,他将我们生成的映射脚本转换成SQL语句在指定的数据库中执行,在数据库中生成或修改表。
migrate参数
默认情况下,migrate会将所以APP中的映射脚本映射进入数据库
migrate参数 | 作用 |
---|---|
APP名称 | 将一个或多个APP名称下的迁移脚本映射到数据库中。 |
APP名称 映射脚本 | 将某个app下指定名字的migration文件夹中的指定映射脚本映射到数据库中。 |
--fake | 可以将指定的迁移脚本名字添加到数据库中。但是并不会把迁移脚本转换为SQL语句,修改数据库中的表。 |
--fake-initial | 将第一次生成的迁移文件版本号记录在数据库中。但并不会真正的执行迁移脚本。 |
其中--fake
与--fake-intial
常用于解决迁移版本时报错使用,下方会详细讲解
showmigrations(查看迁移文件)
查看某个app下的迁移文件。如果后面没有app,那么将查看INSTALLED_APPS中所有的迁移文件。(此命令使用较少,大部分现代IDE中都会携带当前项目目录)
sqlmigrate(迁移使用SQL)
查看某个迁移文件在映射到数据库中的时候,转换的SQL语句
python manage.py sqlmigrate APP名 迁移脚本名
,比如说下图第四个迁移脚本名为
0004_delete_text
除了写全民外,简写成编号也同样可以查询出来
python manage.py sqlmigrate APP名 迁移脚本编号
编号需要完整编号,比如第四个要写成0004,不能是4
migrations中的迁移版本常见报错
django.db.utils.OperationalError: (1091, “Can’t DROP ‘***’; check that column/key exists”)解决方案
–fake
如果我们无意中删除了某个映射文件,当我们想要再次将映射脚本映射进入数据库时就可能引发此报错,如何解决此报错就需要用到我们上面提到过的migrate中的--fake
伪造一个假的数据库文件放入数据库
假设我们当前有如下图的项目,当前项目我已经映射进入数据库中,并且当前一切正常
如果我不小心删除了数据库中其中0003这个映射数据
我们再次执行,就发现其报错django.db.utils.OperationalError: (1091, "Can't DROP '***'; check that column/key exists")
这种时候,我们的解决方法为现找到我们对应不上的表
然后在执行python manage.py migrate field --make APP名 表名
,比如我这里执行的就为migrate --make field 0003_people_修改日期
或者可以直接执行python manage.py migrate field --make
其会将所有数据库中不存在的映射都自动添加进入数据库。
–fake-initial
上述操作完成的前提是在数据库中缺少了一些映射记录导致的,但如何是在Django项目与数据库中都丢失了一些映射文件,或发生了其他更为复杂的情况这时候我们就需要使用--fake-initial
这个方法来处理了
这种时候我们先将Django中的出现问题的APP中的migrations中所以迁移文件都删除(保留__init__.py),然后在将数据库中django_migrations
表中的出问题APP的所有记录删除,
然后这一步很关键将出问题APP的ORM模型(modls.py)中字段和数据库中的字段对应,如果出现不对应的情况修改models.py文件,多的注释,少的添加(这时候注释或添加的表头,等数据库和模型正常即可正常在添加或删除回去)
完成上述操作后,在执行python manage.py makemigrations APP名
和
python manage.py migrate --fake-initial
,将其映射进入数据库即可。
更多推荐
所有评论(0)