Django 1.7マイグレーションでは、ドロップされたテーブルは再作成されません。なぜですか？
Django 1.7移行を使用します。
データベースに誤ってテーブルをドロップしました。移行を再度実行すると、テーブルが再作成されますが、no、Djangoは「適用する移行はありません」と述べています。
Djangoを取得してテーブルを再作成するには？
私は実行しました：
> makemigrations - No changes detected
> migrate - No migrations to apply.
モデルに変更を加えて新しい移行を実行しようとしましたが、「テーブル 'x.test_customer'は存在しません」と表示されますが、これは正しいですが、テーブルを再作成することを望んでいました。
移行はモデルの違いをチェックし、それをアクションに変換します。アクションはSQLに変換されます。それはしない自動的にdbスキームをモデルと同期し、あなたがテーブルを落としたことを知る方法がありません（手動の変更については知りません）なぜなら、手動で変更する必要はないからです。それがポイントです）
答え？手動の変更には手動の移行も必要です。あなたがする必要があるのは、単にあなた自身の移行を書き、テーブルを再構築するように南に手動で指示することです。それほど難しくありません ドキュメント とても簡単にします。次のようなものを作成します。
from Django.db import migrations, models
class Migration(migrations.Migration):
operations = [
migrations.CreateModel("Foo"),
migrations.AddField("Foo", "bar", models.IntegerField(default=0))
]
おそらく最初の移行ファイル（最初にモデルを作成したファイル）を調べて、ほとんどすべてをコピーして貼り付けることができます。あとは、いつものように移行を実行するだけです
データベースに移動して、テーブルを見つけますDjango_migrations。 appがアプリ名に等しいすべての行を削除します。
その後、makemigrationsを実行し、migrateが機能します。
私が見つけて完全に動作する別のソリューション：
In Django 1.7：
移行フォルダーを削除する
データベース内：
DELETE FROM Django_migrations WHERE app = 'app_name'。または、このテーブルを切り捨てることもできます。
python manage.py makemigrationspython manage.py migrate --fake
In Django 1.9.5：
- 移行フォルダーを削除する
データベース内：
DELETE FROM Django_migrations WHERE app = 'app_name'。または、このテーブルを切り捨てることもできます。
python manage.py makemigrations app_namepython manage.py migrate
これは私のために100％動作します！
実際にこれを行う簡単な方法を見つけました。存在しないものをロールバックしたことを偽造してから、再移行します。移行0005がテーブルを作成する移行であった場合：
python manage.py migrate myapp --fake 0004
python manage.py migrate myapp
その後は良いはずです！
後のものをスキップする必要がある場合、これを行います：
python manage.py migrate myapp --fake 0004
python manage.py migrate myapp 0005
python manage.py migrate myapp --fake
その後は良いはずです！
Django> = 1.9でこれを行う最も簡単な方法は、次を実行することです。
./manage.py migrate app_name zero
これにより、テーブルが削除され、すべての移行が元に戻ります。
完全な免責事項、これは場合によっては破壊的な操作であり、ほとんどの場合、DBに影響を与えずにシステムの一部を再移行するために使用します。
テーブルDjango_migrations経由で試しましたか？アプリのラベルにマップされている行と問題の移行名を削除して、それらの行を削除します。
+----+-----------------------+----------------------------------------------------------+---------------------+
| id | app | name | applied |
+----+-----------------------+----------------------------------------------------------+---------------------+
| 1 | contenttypes | 0001_initial | 2015-03-07 16:32 |
| 30 | homepage | 0001_initial | 2015-04-02 13:30:44 |
| 31 | homepage | 0002_auto_20150408_1751 | 2015-04-08 12:24:55 |
| 32 | homepage | 0003_remove_mappinghomepagemoduleinventory_inventoryinfo | 2015-04-09 08:09:59 |
+----+-----------------------+----------------------------------------------------------+---------------------+
したがって、homepageを削除する場合は、行30、31、32を削除するだけです。
もちろん、テーブルも削除したので、Django_content_typeも変更する必要があります。
+----+----------------------------------------+-----------------------+--------------------------------------+
| id | name | app_label | model |
+----+----------------------------------------+-----------------------+--------------------------------------+
| 1 | content type | contenttypes | contenttype |
| 2 | session | sessions | session |
| 3 | site | sites | site |
| 92 | master_homepagemodule_extrafields | homepage | masterhomepagemoduleextrafields |
| 93 | mapping_homepagemodule_inventory | homepage | mappinghomepagemoduleinventory |
| 94 | master_homepagemodule_inventoryfields | homepage | masterhomepagemoduleinventoryfields |
| 95 | mapping_homepagemodule_inventoryfields | homepage | mappinghomepagemoduleinventoryfields |
| 96 | master_homepagemodule | homepage | masterhomepagemodule |
| 97 | mapping_homepagemodule_extrafields | homepage | mappinghomepagemoduleextrafields |
+----+----------------------------------------+-----------------------+--------------------------------------+
そのため、これらのテーブルの行を削除することで、再移行する必要があるテーブルを削除する必要があります。
時間が足りず、手早く汚れた修正が必要なとき、または開発中に遊んでいるときにこれを使用しました。
あなたにも役立つことを願っています！
削除されたテーブルを再作成するためのDjango 2.0.2の場合、myappでモデルをコメント化してから--fakeで移行し、モデルのコメントを外して移行する必要がありました--fakeなし
- 目的のアプリで移行ファイルを削除します
- Raulの回答に感謝：データベース内：
DELETE FROM Django_migrations WHERE app = 'app_name'。 models.pyのコメントコードとviews、signalsなど（エラーを防ぐため）でのこのすべてのモデルの使用法。python manage.py makemigrations YOUR_APP_NAMEpython manage.py migrate --fake- ステップ3でコメントした内容のコメントを外します
python manage.py makemigrations YOUR_APP_NAME- migrate -fakeなし：
python manage.py migrate
これにより、一部のユーザーの問題が解決するはずです。
わかりましたので、私がしたことは、移行を台無しにしないことでした。移行でたびたびトラブルが発生するようです。そして、この場合、移行をリプレイしようとしても何も得られませんでした。サウスヴィンテージの移行と新しい1.7の移行があったことを助けなかったかもしれません。
環境：postgres 9.3
基本的に、データベースの古いバックアップを復元しました空のデータベースに。次に、postgres adminユーティリティで復元ターゲットを起動し、各テーブルの説明からテーブルをコピーして貼り付けました（4つしかありませんでした）。テストデータベースに切り替えて、pgのsqlユーティリティで実行しました。
データを失うことなく生きていられる限り、問題がある場合（手動でidフィールドのシーケンスが機能していないかのように見えます）、テーブルを手動で削除するのは無理だとは思いません。そのユースケースでは、移行は回復力があるはずです。
Djangoを学習する小さなアプリを作成しているときにこれに遭遇しました。既存のテーブルにnull以外の列を作成したかった。 3つのステップがありました。
- テーブルを落とす
- django_migrationsのレコードを削除します
- 問題のテーブルの移行を削除します
- このステップの前に「python manage.py makemigrations posts」を実行すると、「null不可フィールドを追加しようとしています」というメッセージが表示されます。
実際のアプリケーションでは、他の人が指摘したようにデフォルト値を提供する必要があります。