Перенос 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 не работала), если вы можете жить с потерей своих данные. Миграции должны быть устойчивыми в этом случае.