Как устранить ошибку миграции базы данных из-за изменения имени файла миграции?
Я все еще довольно новичок в Python, а также в Django, поэтому у меня возникла ситуация, которую я не уверен, как разрешить.
Основная проблема заключается в том, что при развертывании моего кода на dev, развертывание не происходит, на stage или prod оно проходит.
Я работал над проблемой, когда мне нужно было удалить некоторые столбцы в таблице в нашем приложении. После внесения изменений я развернул приложение в dev и попросил провести обзор кода. В обзоре кода было предложено изменить имя файла миграции на более описательное, а не просто оставить его 0018_auto_.
Я сделал это изменение и развернул на dev и stage. Dev потерпел неудачу (когда я ожидал успеха), потому что новое имя было замечено, и django попытался отбросить колонки, которые больше не существуют. В stage имя не было изменено, и колонки были сброшены в первый раз, используя это новое имя файла.
Так что этап развертывается просто отлично.
Как мне разрешить эту ошибку на dev, чтобы он признал, что миграция уже произошла?
Спасибо!
Если вы на 100% уверены, что единственным изменением, сделанным для 0018, было имя файла, и что это последняя миграция для вашего приложения, вы можете сделать:
python manage.py migrate myapp 0017 --fake # Move to 17 without removing changes done by 18
python manage.py migrate myapp 0018 --fake # 18 is already applied, so just migrate with the new filename
Это сохранит изменения, которые присутствуют в 0018, и просто применит изменения к имени файла.
Django строит таблицу с именем djang_migrations, которая отслеживает миграции, которые были применены. Если вы позже измените имя файла миграции, то это будет выглядеть так, как будто миграция не была запущена.
Вы можете переименовать миграцию в таблице django_migrations вашей среды разработки с помощью:
UPDATE django_migrations
SET name = '0018_new_name'
WHERE app = '%%%name_of_the_app'
AND name = '0018_auto_'где 0018_new_name - новое имя файла миграции.
Обновляя это имя, Django теперь должен считать новый файл миграции выполненным.
Все это были отличные ответы и, несомненно, помогут другим сейчас и в будущем!
Я перепробовал все эти ответы, но сработало только одно. Долгий путь!
Для полной видимости (это работало локально и я понимаю - фейк теперь на практике, спасибо @brian-destura!):
python manage.py migrate myapp 0017 --fake # Move to 17 without removing changes done by 18
python manage.py migrate myapp 0018 --fake # 18 is already applied, so just migrate with the new filename
При развертывании через gitlab, наше приложение django / zappa просто не хотело успешно развертываться (даже с множеством различных решений).
В итоге единственным способом исправить проблему было обновление файла миграции 0018 для добавления всех этих полей, откат изменений в моделях и сериализаторах и повторное развертывание в dev.
После этого верните все изменения, включая файл миграции, и снова разверните на dev.
Вероятно, есть более простой способ сделать это, но поскольку все те, у кого больше знаний о бэкенде, уехали на праздники (я изначально фронтэндщик, у меня больше знаний о бэкенде/проектов за последний год), я был очень рад решить и выпустить свои изменения.
Спасибо вам, ребята, за некоторые вещи, которые можно попробовать, идеи и знания о защите, которые я мог бы использовать для создания этого, моего собственного длинного решения!