學(xué)過Django的都知道Django使用migrate來做數(shù)據(jù)庫的更新(在數(shù)據(jù)庫中執(zhí)行語句),但有些時(shí)候我們?cè)谑褂胢igrate的時(shí)候會(huì)遇到一些migrate報(bào)錯(cuò),那么怎么解決這些migrate報(bào)錯(cuò)呢?接下來這篇文章告訴你。
前言
在講解如何解決migrate
報(bào)錯(cuò)原因前,我們先要了解migrate
做了什么事情,migrate
:將新生成的遷移腳本。映射到數(shù)據(jù)庫中。創(chuàng)建新的表或者修改表的結(jié)構(gòu)。
問題1:migrate怎么判斷哪些遷移腳本需要執(zhí)行?
它會(huì)將代碼中的遷移腳本和數(shù)據(jù)庫中django_migrations
中的遷移腳本進(jìn)行對(duì)比,如果發(fā)現(xiàn)數(shù)據(jù)庫中,沒有這個(gè)遷移腳本,那么就會(huì)執(zhí)行這個(gè)遷移腳本。
問題2:migrate做了什么事情
- 將相關(guān)的遷移腳本翻譯成SQL語句,在數(shù)據(jù)庫中執(zhí)行這個(gè)SQL語句。
- 如果這個(gè)SQL語句執(zhí)行沒有問題,那么就會(huì)將這個(gè)遷移腳本的名字記錄到
django_migrations
中。
實(shí)戰(zhàn)案例
當(dāng)我們了解清楚migrate
的作用后,我們來看一個(gè)案例
首先我們創(chuàng)建一個(gè)項(xiàng)目orm_migrations_demo
,接著創(chuàng)建2個(gè)app應(yīng)用front
和article
,代碼結(jié)構(gòu)如下圖
接著在front.models.py
和article.models.py
中創(chuàng)建模型
# front.models.py
class Article(models.Model):
name = models.CharField(max_length=200)
# article.models.py
class FrontUser(models.Model):
name = models.CharField(max_length=200)
接著在settings.py
的INSTALL_APPS
中將app注冊(cè)
INSTALLED_APPS = [
'django.contrib.admin',
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.messages',
'django.contrib.staticfiles',
'front',
'article',
]
接著我們打開命令行,輸入makemigrations article
,再輸入makemigrations front
,此時(shí)2個(gè)app目錄中都會(huì)出現(xiàn)遷移文件0001_initial.py
,此時(shí)數(shù)據(jù)庫中是沒有表的,因?yàn)檫€沒有執(zhí)行遷移命令
接著我們執(zhí)行migrate article
,再輸入migrate front
,migrate發(fā)現(xiàn)數(shù)據(jù)庫中沒有遷移腳本,那么就會(huì)執(zhí)行剛才生成的2個(gè)遷移腳本,將遷移腳本翻譯成SQL語句,然后創(chuàng)建了2張表,執(zhí)行完成后,會(huì)將遷移腳本記錄到django_migrations
表中,數(shù)據(jù)庫中表結(jié)構(gòu)如下:
django_migrations
表中內(nèi)容如下:
接下來我們?cè)?code>article.models.py中添加一個(gè)content
字段
class Article(models.Model):
name = models.CharField(max_length=200)
content = models.CharField(max_length=200, null=True)
然后執(zhí)行命令makemigrations article
,會(huì)在項(xiàng)目中生成遷移文件0002_article_content.py
,接著執(zhí)行migrate article
,執(zhí)行遷移腳本,此時(shí)數(shù)據(jù)庫中表django_migrations
有3個(gè)遷移腳本
現(xiàn)在我們來模仿錯(cuò)誤信息內(nèi)容,我們將數(shù)據(jù)庫中django_migrations
表中的0002_article_content
這行記錄刪除,然后我們來看下0002_article_content
的代碼
class Migration(migrations.Migration):
dependencies = [
('article', '0001_initial'),
]
operations = [
migrations.AddField(
model_name='article',
name='content',
field=models.CharField(max_length=200, null=True),
),
]
這個(gè)遷移腳本的作用是為article模型添加content
字段,但是我們現(xiàn)在看一下article
中的字段:
從上圖中我們可以清楚的看到article
表中已經(jīng)有了content
字段,那么我們?cè)賵?zhí)行migrate article
命令時(shí),就會(huì)報(bào)錯(cuò),說content字段重復(fù)了,報(bào)錯(cuò)信息如下
django.db.utils.OperationalError: (1060, "Duplicate column name 'content'")
如果發(fā)生這種報(bào)錯(cuò)信息,解決辦法是在migrate
命名后添加參數(shù)--fake
,--fake
可以將指定的遷移腳本名字添加到數(shù)據(jù)庫中。但是并不會(huì)把遷移腳本轉(zhuǎn)換為SQL語句去修改數(shù)據(jù)庫中的表
所以,我們可以執(zhí)行命名migrate article --fake
,會(huì)在django_migrations
表中插入遷移腳本記錄0002_article_content
,如下圖
此時(shí)數(shù)據(jù)庫中表結(jié)構(gòu)和django中的表結(jié)構(gòu)完全一致,接下來執(zhí)行遷移命令,就不會(huì)報(bào)錯(cuò)了
第一種報(bào)錯(cuò)情況總結(jié)
原因:執(zhí)行migrate
命令會(huì)報(bào)錯(cuò)的原因是。數(shù)據(jù)庫的django_migrations
表中的遷移版本記錄和代碼中的遷移腳本不一致導(dǎo)致的。
解決辦法:使用--fake
參數(shù):首先對(duì)比數(shù)據(jù)庫中的遷移腳本和代碼中的遷移腳本。然后找到哪個(gè)不同,之后再使用--fake
,將代碼中的遷移腳本添加到django_migrations
中,但是并不會(huì)執(zhí)行sql語句。這樣就可以避免每次執(zhí)行migrate
的時(shí)候,都執(zhí)行一些重復(fù)的遷移腳本。
第二種報(bào)錯(cuò)情況
如果我們不管怎么執(zhí)行migrate
命令都會(huì)報(bào)錯(cuò),那么就執(zhí)行第二種方案
將出問題的app下的所有模型,都和數(shù)據(jù)庫中的表保持一致。將出問題的app下的所有遷移腳本文件都刪掉。再在django_migrations
表中將出問題的app相關(guān)的遷移記錄都刪掉。使用makemigrations
,重新將模型生成一個(gè)遷移腳本。使用migrate --fake-initial
參數(shù),將剛剛生成的遷移腳本,標(biāo)記為已經(jīng)完成(因?yàn)檫@些模型相對(duì)應(yīng)的表,其實(shí)都已經(jīng)在數(shù)據(jù)庫中存在了,不需要重復(fù)執(zhí)行了。)可以做其他的映射了。
到此這篇Django migrate報(bào)錯(cuò)的解決方案就介紹到這了,更多Django 相關(guān)知識(shí)請(qǐng)搜索W3Cschool以前的文章或繼續(xù)瀏覽下面的相關(guān)文章。