djanogoのmigrationにはまった


models.pyに子テーブルJournalistを書いてmakemigrations

models.py
from django.db import models

class Journalist(models.Model):
    first_name = models.CharField(max_length=60)
    last_name = models.CharField(max_length=60)
    biography = models.TextField(blank=True)
    def __str__(self):
        return f"{self.first_name } { self.last_name }"

class Article(models.Model):
    author = models.ForeignKey(Journalist, on_delete=models.CASCADE, related_name="articles")
    # author = models.CharField(max_length=50)
    title = models.CharField(max_length=120)
    description = models.CharField(max_length=200)
    body = models.TextField()
    location = models.CharField(max_length=120)
    publication_date = models.DateField()
    active = models.BooleanField(default=True)
    created_at = models.DateTimeField(auto_now_add=True)
    updated_at = models.DateTimeField(auto_now=True)

    def __str__(self):
        return f"{self.author } { self.title }"

するとエラーが発生。内容はJohnはintegerじゃないよ的な感じだった気がする。
なんの話?ってな感じでもう一回migrateするとエラーがJournalistテーブルは存在しているに変わっていた。
とりあえずmysqlを確認すると確かに存在しており、さっきのmigrateで追加されたんだろうと考えJournalistテーブルをdrop。
するとまたJohnはintegerじゃないよ的なこと言われてそこで気づいた。
テーブルarticleのauthorのデータはforeignkeyなので、integerでなければいけないはずなのに、子テーブルを作る前のデータが残っていたため、authorカラムに文字列入ってるぞと怒っていたようだ

そこでテーブルのデータをtruncateしておけばよかったのに、親テーブルArticleをdrop。
そして再度makemigrations、migrateの流れでやるとなぜかnothing to migrateが出る。
mysqlで確認しても明らかにテーブルは作成されていなかった。
migrationsファイル内を消したり思いつくことをある程度やってもうまくいかなかったので、migration リセットで調べると解決策が見つかった。

terminal
python manage.py migrate --fake [アプリ名] zero

次にmigrationsディレクトリ内の『__ init__.py』ファイル以外のすべてのファイルを削除
あとはいつも通り

terminal
python manage.py makemigrations
python manage.py migrate

ついでに、以下のコマンドでmigrationの確認ができるっぽい

terminal
python manage.py showmigrations

参考にさせて頂いたサイト

因みに今のdbのモデルを確認する方法

python manage.py inspectdb --database sth