Джанго: Безопасное удаление старых миграций?

Question

У меня есть приложение Django с множеством устаревших миграций.Я хотел бы удалить старые миграции и начать все заново.

Приложение имеет 14 различных папок «миграции».

Вот как выглядят некоторые из них:

Безопасно ли удалять все содержимое с каждого изэти папки?Или я должен обязательно удалить только некоторые файлов - и если да, то какие файлы?

Answer 1

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

Если у вас нет постоянных баз данных, тогда да, вы можетеудалите все миграции, запустите python manage.py makemigrations --initial, и он создаст новые миграции на основе ваших текущих моделей.

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

.pyc-файлы, как правило, безопасно удалить, при условии, что соответствующие .py-файлы все еще там.

ваш первый снимок экрана не Djangoи выглядит как какой-то проект JS.

Answer 2

1. Файлы json и js не связаны с миграциями django, а также с папкой __pycache__.Вы можете удалить все из них.
2. Если вы имеете в виду «ранее применено и больше не нужно, так как проекту требуется только последняя версия миграций», вы не хотите удалять, а squash вместо этого с squashmigrations, что уменьшает файлы, которые выдва, файл инициализации и исходный файл миграции, таким образом ваш проект все еще работает.
3. Если под удалением вы имеете в виду, что они вам больше не нужны, потому что вы уже настолько изменили модели, что предыдущие миграции не не имеет значения, даже если его использовать, кроме того, что его применяли и не применяли, даже не используя, перейдите к шагу 2 и вместо удаления файлов вручную. Когда вы по одному создаете миграции в своих приложениях, вытакже создайте дерево зависимостей миграции, ну, Django делает.И это действительно трудно отследить после некоторого момента, если вы попытаетесь удалить все, думая, что вы можете легко создать новые файлы миграции, поверьте мне, как человеку, который испытал иначе, это не работает так.Гораздо проще позволить django обрабатывать сжатие миграции, это оптимизирует миграцию, означая, что оно также удаляет неиспользуемые в вашем конечном состоянии.

Больше читать по адресу: https://docs.djangoproject.com/en/2.2/topics/migrations/#migration-squashing

Answer 3

Вам следует никогда просто удалять миграции перед их отменой, или это будет кошмаром, когда вы захотите применить новые миграции.

Чтобы отменить миграции, вам необходимо сделать следующее:

1. Используйте python manage.py migrate your_app_name XXXX на случай, если вы хотите отменить миграции после миграции XXXX.В противном случае используйте python manage.py your_app_name zero, чтобы полностью отменить все миграции.

2. Удалите файлы .pyc из / migrations / __ pycache __ /, которые вы не применили.

3. Удалите файлы .py в миграциях / которые вы не применили.

Теперь вы можете создавать новые миграции без каких-либо головных болей.

Если то, что вы ищетеДля того, чтобы объединить все миграции в одну, выполните описанные выше шаги, удалив все миграции, а затем запустите python manage.py makemigrations your_app_name, чтобы создать один файл миграции.После этого просто наберите python manage.py migrate your_app_name и все готово.

Answer 4

Отметив один из предоставленных ранее ответов как принятый, вот краткое изложение нескольких вещей, которые я узнал:

• Удаление миграций Django, как правило, плохая идея .
• Django отслеживает, что находится в вашей БД, через эти файлы миграции, а также через таблицу, которую он создает в вашей БД, и если вы удалите какую-либо из этих Django, то начнет выдавать ошибки на migrate, которые могут бытьтрудно исправить.

Я получал некоторые из этих ошибок, которые трудно исправить.Вот что я сделал, чтобы это исправить:

• Ran migrate на рабочем сервере.
• Когда я получу ошибку, он скажет мне, как БД не синхронизированс тем, что ожидал Джанго.Я исправил это вручную путем непосредственного редактирования БД с помощью клиента SQL.
• Например, если указано, что существует ключ, которого не должно быть, я удалил соответствующий индекс из указанной таблицы.
• Или, если в нем говорится, что существует таблица, которая не должнасуществует, я сделал резервную копию таблицы в файл и удалил таблицу.Migrate затем создал таблицу, а затем я снова заполнил ее данными из резервной копии.
• В случае таблиц "многие ко многим", когда Django заново их создал, я удалил все новые Django.-создал таблицы и восстановил их из резервной копии, созданной в моей локальной системе разработки, на которой уже были запущены все последние миграции.

В конце концов я смог успешно завершить все миграции.

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