Миграции Django 1.7 не будут воссоздавать удаленную таблицу, почему?
использование миграции Django 1.7.
я случайно уронил таблицу в свою базу данных. Я предположил, что, запустив миграцию снова, это воссоздаст таблицу, но нет, Django заявляет "Нет миграции для применения".
Как заставить Django воссоздать таблицу?
Я:
> makemigrations - No changes detected
> migrate - No migrations to apply.
Я попытался внести изменения в модель и запустить новую миграцию, и в ней просто говорится, что "таблица" x.test_customer" не существует", что правильно, но я надеялся, что он воссоздаст таблицу.
8 ответов
миграции проверьте различия в ваших моделях, а затем преобразует это в действия, которые преобразуются в SQL. Это не автоматическая синхронизация схемы БД с вашими моделями, и у нее нет способа узнать, что вы уронили таблицу (она не знает о ручных изменениях, потому что, ну, вы не должны делать ручные изменения. Вот в чем дело)
ответ? ручное изменение требует ручная миграция также. Что вам нужно сделать, это просто написать ваша собственная миграция и вручную скажите south, чтобы заново построить таблицу. Это не очень трудно, документы сделать это довольно просто. Просто сделайте что-то вроде этого:
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
будет работать.
другое решение, которое я нашел и отлично работает:
в Django 1.7:
удалить папке migrations
-
в базе:
DELETE FROM django_migrations WHERE app = 'app_name'
.вы можете альтернативно просто усечь эту таблицу.
python manage.py makemigrations
python manage.py migrate --fake
в Джанго 1.9.5:
- удалить миграций папка
-
в базе:
DELETE FROM django_migrations WHERE app = 'app_name'
.вы можете альтернативно просто усечь эту таблицу.
python manage.py makemigrations app_name
python 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_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 >= 1.9-запустить следующее:
./manage.py migrate app_name zero
это удалит ваши таблицы и вернет все миграции.
хорошо, поэтому я не стал связываться с миграциями. Похоже, у меня проблемы с миграциями. И в этом случае попытка повторить миграцию ни к чему не привела. Возможно, не помогло то, что были некоторые миграции на юг, а также более новые 1.7.
окружающая среда: postgres 9.3
в основном, я восстановил старую резервную копию моей базы данных в пустую базу данных. Затем я поднял цель восстановления в Администраторе postgres утилита и копирование / вставка таблиц create из описания каждой таблицы (мне нужно было всего 4). Переключился на мою тестовую базу данных и запустил ее в утилите sql pg.
Я не знаю, я не думаю, что неразумно отбрасывать таблицу вручную, если у вас возникли проблемы с ней (мне показалось, что последовательность моего поля идентификатора не работает), пока вы можете жить с потерей своих данных. В этом случае миграции должны быть устойчивыми.
в моем случае в django 2.0.2
для воссоздания упавшей таблицы мне нужно было прокомментировать мои модели в myapp
а затем мигрировать с --fake
и раскомментируйте мои модели и миграции без --fake
Немного отличается от ответа Рауля:
- удалите файлы миграции в нужном приложении
- спасибо Раулю ответ: в базе данных:
DELETE FROM django_migrations WHERE app = 'app_name'
. - кодексы комментарий
models.py
и все это использование моделей вviews
,signals
и etc (к предотвратить ошибку). python manage.py makemigrations YOUR_APP_NAME
python manage.py migrate --fake
- un-comment то, что вы прокомментировали в шаге 3
python manage.py makemigrations YOUR_APP_NAME
- перенос без -- fake:
python manage.py migrate
это должно решить некоторые проблемы пользователей.