Перенос Django 1.7 не воссоздает упавшую таблицу, почему?
Использование миграции Django 1.7.
Я случайно сбросил таблицу в моей базе данных. Я предположил, что снова выполнив миграцию, это воссоздает таблицу, но нет, Django заявляет: "Никаких миграций для применения".
Как заставить Django воссоздать таблицу?
Я запустил:
> makemigrations - No changes detected
> migrate - No migrations to apply.
Я попытался внести изменения в модель и запустить новую миграцию и просто заявляет, что "Таблица" x.test_customer "не существует", что является правильным, но я надеялся, что он воссоздает таблицу.
Ответы
Ответ 1
Миграции проверяют различия в ваших моделях, а затем переводит их на действия, которые переводится на SQL. Он не выполняет автоматически синхронизирует схему db с вашими моделями и не знает, что вы уронили таблицу (она не знает о ручных изменениях, потому что, ну, вы не должны делать ручные изменения. Это пункт)
Ответ? для ручного изменения также требуется ручная миграция. Вам нужно просто написать собственную миграцию и вручную указать югу, чтобы перестроить таблицу. Это не очень сложно, Документы делают это довольно легко. Просто сделайте что-то вроде этого:
from django.db import migrations, models
class Migration(migrations.Migration):
operations = [
migrations.CreateModel("Foo"),
migrations.AddField("Foo", "bar", models.IntegerField(default=0))
]
Вероятно, вы можете посмотреть первый файл миграции (тот, который сделал модель в первую очередь), и скопировать пасту почти все. Тогда все, что вам нужно сделать, это запустить миграцию, как вы всегда делаете
Ответ 2
Перейдите в свою базу данных и найдите таблицу django_migrations
. Удалите все строки с app
равными имени вашего приложения.
Затем выполняются операции makemigrations
и migrate
.
Ответ 3
Другое решение, которое я нашел и прекрасно работает:
В django 1.7:
-
Удалить папку миграций
-
В базе данных: DELETE FROM django_migrations WHERE app = 'app_name'
.
Вы можете просто обрезать эту таблицу.
-
python manage.py makemigrations
-
python manage.py migrate --fake
В django 1.9.5:
- Удалить папку миграции
-
В базе данных: DELETE FROM django_migrations WHERE app = 'app_name'
.
Вы можете просто обрезать эту таблицу.
-
python manage.py makemigrations app_name
-
python manage.py migrate
Это работает на 100% для меня!
Ответ 4
На самом деле я нашел более простой способ сделать это. Вы подделываете то, что вы откатываете то, чего не существует, а затем переадресовываете. Если ваша миграция 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
Должно быть хорошо после этого!
Ответ 5
Полный отказ от ответственности, в некоторых случаях это деструктивная операция, и я в основном использую ее для ремиграции частей системы, не затрагивая БД.
Вы пытались сделать это через таблицу 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 |
+----+----------------------------------------+-----------------------+--------------------------------------+
Итак, теперь вам нужно будет удалить таблицы, необходимые для ремиграции, путем удаления строк для этих таблиц.
Я использовал это, когда время было скудным, и нам нужно было быстрое грязное исправление или когда играли в разработке.
Надеюсь, это тоже поможет!
Ответ 6
Самый простой способ сделать это на django >= 1.9 - запустить следующее:
./manage.py migrate app_name zero
Это удалит ваши таблицы и вернет все миграции.
Ответ 7
ОК, так что я сделал это, чтобы не путаться с миграциями. Похоже, я часто сталкиваюсь с проблемами миграции. И в этом случае попытка перепрограммировать миграции не дала мне никуда. Возможно, не помогли, что были некоторые южно-винтажные миграции, а также новые вещи 1.7.
окружающая среда: postgres 9.3
В принципе, я восстановил старую резервную копию моей базы данных в пустой базе данных. Затем я поднял цель восстановления в утилите администратора postgres и скопировал/вставил таблицы создания из каждого описания таблицы (мне осталось всего 4). Переключился на мою тестовую базу данных и запустил ее в утилите pg sql.
Я не знаю, я не думаю, что было бы необоснованным отказаться от таблицы вручную, если у вас возникли проблемы с ней (посмотрел на меня так, как будто моя последовательность полей ID не работала), если вы можете жить с потерей своих данные. Миграции должны быть устойчивыми в этом случае.