Миграции Django 1.7 не воссоздают упавший стол, почему?

Question

Использование миграции Django 1.7.

Я случайно уронил стол в своей базе данных. Я предположил, что повторение миграции снова приведет к воссозданию таблицы, но нет, Django заявляет: «Никаких миграций для применения».

Как я могу заставить Django воссоздать таблицу?

Я бежал:

> makemigrations - No changes detected 
> migrate - No migrations to apply. 

Я попытался сделать изменения в модели и запуск новой миграции и просто говорится, что «„x.test_customer“таблица не существует», который является правильным, но я надеялся, что он воссоздает таблицу.

Answer 1

Миграции проверяют различия в ваших моделях, а затем переводим их на действия, которые переводятся на SQL. Это не автоматически синхронизирует схему db с вашими моделями, и у нее нет способа узнать, что вы уронили таблицу (она не знает о ручных изменениях, потому что, вы не должны делать ручные изменения. точка)

Ответ? для ручного изменения требуется ручной миграции, а также. Вам нужно просто написать собственную миграцию и вручную указать югу, чтобы перестроить таблицу. Это не очень сложно, The docs сделать это довольно легко. Просто сделать что-то вроде этого:

from django.db import migrations, models 

class Migration(migrations.Migration): 

    operations = [ 
     migrations.CreateModel("Foo"), 
     migrations.AddField("Foo", "bar", models.IntegerField(default=0)) 
    ] 

Вы, наверное, можете посмотреть в первый миграционный файл (тот, который сделал модель в первую очередь) и скопировать приклеить почти все. Тогда все, что вам нужно сделать, это запустить миграцию, как вы всегда делаете

Answer 2

Я действительно нашел более простой способ сделать это. Вы подделываете то, что вы откатываете то, чего не существует, а затем переадресовываете. Если ваша миграция 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 

Должно быть хорошо после этого!

Answer 3

ОК, так что я сделал это, чтобы не возиться с миграциями. Похоже, я часто сталкиваюсь с проблемами миграции. И в этом случае попытка перепрограммировать миграции не дала мне никуда. Возможно, не помогли, что были некоторые южно-марочные миграции, а также новые вещи 1.7.

среда: Postgres 9,3

В принципе, я восстановил старую резервную копию моей базы данных в пустую базу данных. Затем я поднял цель восстановления в утилите администратора postgres и скопировал/вставил таблицы создания из описания каждой таблицы (мне осталось только 4). Переключившись на мою тестовую базу данных, & запустил ее в утилите pg sql.

Я не думаю, что было бы неоправданно бросать стол вручную, если у вас возникли проблемы с ним (смотрел на меня так, как будто последовательность моего идентификационного поля не работала), если вы можете жить с потерей ваши данные. Миграции должны быть устойчивыми в этом случае.

Answer 4

Полный отказ от ответственности, в некоторых случаях это разрушительная операция, и я в основном использую ее для ремиграции частей системы, не затрагивая БД.

Вы пробовали сделать это через стол 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  | 
+----+----------------------------------------+-----------------------+--------------------------------------+ 

Так что теперь вам нужно будет удалить таблицы, необходимые для ремиграции, путем сброса строк для этих таблиц.

Я использовал это, когда время было мало, и нам нужно было быстрое грязное исправление или когда играли в процессе развития.
Надеюсь, это поможет вам!

Answer 5

Перейти в вашу базу данных и найти таблицу django_migrations. Удалить все строки, которые имеют app, равно имени вашего приложения.

Затем выполните makemigrations & migrate будет работать.

Answer 6

Другое решение я нашел и отлично работает:

В Джанго 1.7:

1. Удалить ваши миграции FOLDER

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% для меня!

Answer 7

Самый простой способ сделать это на Джанго> = 1.9, чтобы выполнить следующую команду:

./manage.py migrate app_name zero 

Это удалит ваши таблицы и вернуть все миграции.