Миграции 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:

  1. удалить папке migrations

  2. в базе: DELETE FROM django_migrations WHERE app = 'app_name'.

    вы можете альтернативно просто усечь эту таблицу.

  3. python manage.py makemigrations

  4. python manage.py migrate --fake

в Джанго 1.9.5:

  1. удалить миграций папка
  2. в базе: DELETE FROM django_migrations WHERE app = 'app_name'.

    вы можете альтернативно просто усечь эту таблицу.

  3. python manage.py makemigrations app_name

  4. 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 Немного отличается от ответа Рауля:

  1. удалите файлы миграции в нужном приложении
  2. спасибо Раулю ответ: в базе данных:DELETE FROM django_migrations WHERE app = 'app_name'.
  3. кодексы комментарий models.py и все это использование моделей в views, signals и etc (к предотвратить ошибку).
  4. python manage.py makemigrations YOUR_APP_NAME
  5. python manage.py migrate --fake
  6. un-comment то, что вы прокомментировали в шаге 3
  7. python manage.py makemigrations YOUR_APP_NAME
  8. перенос без -- fake: python manage.py migrate

это должно решить некоторые проблемы пользователей.