Django 1.8: создание начальных миграций для существующей схемы

Я столкнулся с этим сценарием, но мне никогда не приходилось удалять базу данных, чтобы решить эту проблему. Обычно я удаляю папку миграции из приложения и удаляю записи миграции из базы данных.

Я бы попытался запустить make migrations по одному приложению за раз. Если какой-либо из приложений полагается на другие таблицы, очевидно, добавьте их в последнюю очередь.

также я обычно просто бегу,python manage.py сделать эмиграцию потом просто python manage.py мигрировать даже с первоначальной миграции он должен работать нормально с Django 1.7 и 1.8.

Джанго ..., 1.8, 1.9, ...

то, что вы хотите достичь, - это раздавить существующие миграции и использовать для них замену.

как сделать это правильно без использования какой-либо команды при освобождении (случай без влияния на базу данных и сотрудников).

1. для каждого приложения, избавиться от своей папке migrations: mv <app>/migrations/ <app>/migrationsOLD/

2. для каждого запуска этого приложения: python manage.py makemigrations <app>.

3. настройка каждой новой миграции:

   • если у вас сложное приложение, или более приложений и связанных с ними моделей между ними, чтобы избежать CircularDependencyError или ValueError: Unhandled pending operations for models:

     подготовьте вторую пустую миграцию в <app>0002_initial2.py (поставьте там зависимость от app_other::0001_initial.py и <app>::0001_initial.py а также-все ForeignKey, M2M, связанные с моделями, созданными на этапе миграции 0001 в других приложениях)

     все должно быть в порядок-иногда для подготовки потребуется больше миграций. Позаботьтесь о dependencies атрибут здесь в каждой миграции.

   • позаботьтесь о начальных значениях-проверьте себя все RunPython действия migrationsOLD и скопируйте код в новую начальную миграцию, если это необходимо.

   • (дополнительно к --fake-initial) добавить initial=True ко всем новым классам миграции (0002 тоже если добавился).

   • добавить replaces атрибут в новом классе миграции. (как собственные, а squashmigrations). Положите туда все старые миграции из <app>

4. проверьте все с помощью makemigrations.

   утверждать "никаких изменений не обнаружила"

5. проверить, если migrate -l показать [x] везде

   утверждать подобное:

   [X] 0001_initial

   [X] 0002_initial2 (102 раздавленных миграции)

пример:

для старый:

0001_initial.py
0002_auto.py
...
0103_auto.py

приготовление:

0001_initial.py
0002_initial2.py  (optional but sometimes required to satisfy dependency)

и добавить к replacesк последнему (0002 здесь, может быть 0001):

replaces = [(b'<app>', '0002_auto.py'), ..., (b'<app>', '0103_auto.py')]

0001_initial.py должен быть назван так же, как старый.

0002_initial2.py это новый, но это замена для старых миграций, поэтому Django будет рассматривать его как загруженный.

если вы используете маршрутизаторы, может быть проблема там. Метод проверки allow_migrate если он выполняется правильно в routers.py. Попробуйте установить возвращаемое значение всегда будет True, и проверить, решает ли это проблему,

def allow_migrate(self, db, app_label, model_name=None, **hints):
    return True

Спасибо-я работал над этой проблемой некоторое время, и ваш список лучших практик был очень удобен. Это может потенциально помочь новичкам на python, как я:

Если вы начинаете с существующего набора моделей, очистите все предыдущие миграции, которые вы сделали!

моя ситуация была я начал с sqlite просто понять django, а затем переключился на MySQL db - и он продолжал бросать 1053 ошибка, вероятно, пытаясь применить предыдущую миграцию он не сделал есть ресурсы для решения...

Если вы все еще получаете эту ошибку при обновлении до Django 1.8, не забудьте сделать makemigrations и перенести отдельно для сторонних приложений, от которых зависят ваши приложения.