В чем разница между --fake-initial
и --fake
в переносах Django? В чем опасность использования поддельных миграций? Кто-нибудь знает? Большое вам спасибо.
Я использую django 1.10
В чем разница между --fake-initial
и --fake
в переносах Django? В чем опасность использования поддельных миграций? Кто-нибудь знает? Большое вам спасибо.
Я использую django 1.10
Ну, документация очень ясно об этом
Позволяет Django пропускать начальную миграцию приложений, если все таблицы базы данных с именами всех моделей, созданных всеми операциями CreateModel в этой миграции, уже существуют. Этот параметр предназначен для использования при первом запуске миграций для базы данных, в которой ранее использовались миграции. Однако этот параметр не проверяет соответствие схемы базы данных за пределами имен таблиц
Вы спрашивали о рисках, ну вот
Безопасно использовать только в том случае, если вы уверены, что ваша существующая схема соответствует тому, что записано в вашей первоначальной миграции.
Сообщает Django пометить миграции как примененные или не примененные, но без фактического запуска SQL для изменения схемы базы данных.
Это предназначено для опытных пользователей для непосредственного управления текущим состоянием миграции, если они вручную применяют изменения;
Еще раз риски четко обозначены
Имейте в виду, что использование --fake может привести к переводу таблицы состояний миграции в состояние, в котором для правильной работы миграций потребуется ручное восстановление.
Этот ответ действителен не только для django версий 1. 8+, но и для других версий.
править ноябрь 2018 года: иногда я вижу ответы здесь и в других местах, которые предлагают вам отказаться от своих данных. Это почти никогда не правильно делать. Если вы удалите свою базу данных, вы потеряете все свои данные.
@e4c5 уже дал ответ на этот вопрос, но я хотел бы добавить еще одну вещь, касающуюся того, когда использовать --fake
и --fake-initial
.
Предположим, у вас есть база данных с производства, и вы хотите использовать ее для разработки и применять миграции, не разрушая данные. В этом случае --fake-initial
пригодится.
--fake-initial
заставит Django просмотреть ваши файлы миграции и в основном пропустить создание таблиц, которые уже есть в вашей базе данных. Однако обратите внимание, что любые миграции, которые не создают таблицы (а скорее изменяют существующие таблицы), будут выполняться.
И наоборот, если у вас есть существующий проект с файлами миграции и вы хотите сбросить историю существующих миграций, то обычно используется --fake
.
Краткий ответ
--fake
не применяет миграцию--fake-initial
может или не может применить миграциюБолее длинный ответ:
--fake
: Django хранит таблицу под названием django_migrations
, чтобы знать, какие миграции он применял в прошлом, чтобы предотвратить случайное повторное их применение. Все, что делает --fake
, это вставляет имя файла миграции в эту таблицу, без фактического запуска миграции. Это полезно, если вы сначала вручную изменили схему базы данных, а затем модели и хотите обойти действия django. Однако на этом этапе вы сами по себе, поэтому будьте осторожны, чтобы не оказаться в противоречивом состоянии.
--fake-initial
: зависит от состояния базы данных
--fake
. Проверяются только имена таблиц, а не их фактическая схема, поэтому, опять же, будьте осторожныОбратите внимание, что --fake-initial
учитывается только в том случае, если файл миграции имеет initial=True
в своем классе, в противном случае флаг игнорируется. Кроме того, это единственное документированное использование initial=True
в миграциях.