Как reset миграции в Django 1.7
(Я знаю, что название такое же, как и это, но вопрос другой).
Мне удалось синхронизировать мои миграции с машиной и производственные миграции.
У меня есть приложение Django, которое использовало Юг. У меня был собственный рабочий процесс, который работал нормально (вероятно, это был не правильный способ делать что-то, но у меня не было никаких проблем с ним).
В основном у меня есть script, который копирует дамп базы данных на мою машину разработки. Он также скопировал файлы миграции. Таким образом, они были синхронизированы, и я мог управлять командами Юга как обычно.
Теперь я обновил до 1.7 и начал использовать миграции. Когда я использую свой предыдущий рабочий процесс (копирование базы данных дампа и файлы миграции из производства), он не обнаруживает изменений на моей машине разработки.
Я прочитал документ миграции, и я вижу, что правильный способ его использования -
- запустите "make migrations" и "migrate" на моей машине разработки.
- запустите "migrate" на моей машине devlopemnt, чтобы фактически внести изменения в базу данных.
- Скопировать изменения, включая файлы миграции.
- запустите "migrate" на производственной машине. (без шага "makemigrations" )
В любом случае. Теперь все беспорядок. Я хотел бы "reset" мои миграции и начать с нуля, делая все правильно с этого момента.
Что мне нужно сделать?
- Удалить содержимое таблицы миграции (на обеих машинах)?
- Удалить содержимое папки переноса? (Включая файл init.py).
- Запустите миграцию в соответствии с документацией для новой.
Я что-то пропустил?
Есть ли причина, по которой копирование всего из производства (базы данных и файлы миграции) не обнаруживает никаких изменений на моей машине разработки впоследствии
Ответы
Ответ 1
Я бы просто сделал следующее в обеих средах (если код один и тот же)
- Удалить папку миграции
- УДАЛИТЬ ИЗ django_migrations WHERE app =
<your app name>
. Вы можете просто обрезать эту таблицу.
-
python manage.py makemigrations
-
python manage.py migrate --fake
После этого все ваши изменения должны быть обнаружены в разных средах.
Ответ 2
Запустить
python manage.py migrate your_app zero
Это приведет к удалению всех таблиц из your_app
Если вы хотите, так как вы сказали, что хотите начать все заново, вы можете удалить свою папку миграций или, возможно, переименовать папку, создать новую папку миграции и запустить
python manage.py makemigrations your_app
python manage.py migrate your_app
Как и на юг, вы всегда можете идти туда и обратно...
# Go to the first migration
python manage.py migrate your_app 0001
# Go to the third migration
python manage.py migrate your_app 0003
Итак, представьте, что ваша 4-я миграция - беспорядок... вы всегда можете перейти на 3-й, удалить 4-й файл миграции и сделать это снова.
Примечание:
Это одна из причин, по которой ваши модели должны быть в разных приложениях. Скажем, у вас есть 2 модели: пользователь и примечание. Хорошей практикой является создание 2 приложений: пользователей и заметок, поэтому миграции не зависят друг от друга.
Не используйте одно приложение для всех своих моделей.
Ответ 3
Небольшое отклонение от ответа на харшил:
$ manage.py migrate --fake <appname> zero
$ rm -rf migrations
$ manage.py makemigrations <appname>
$ manage.py migrate --fake <appname>
Это будет...
- притворяется откатом всех ваших миграций, не касаясь фактических таблиц в приложении
- удалите существующие сценарии миграции для приложения
- создать новую начальную миграцию для приложения
- подделка миграции на начальную миграцию для приложения