Миграции в связке Django и MongoDB нужно делать по выбранному стеку. Если вы используете официальный Django MongoDB Backend, ориентируйтесь на его документацию и обычную логику Django-проекта. Если используете MongoEngine или прямой PyMongo, миграции часто делают отдельными data-скриптами: добавляют поля, меняют структуру документов, пересчитывают значения и проверяют результат
Главная мысль: MongoDB гибкая, но изменения структуры все равно нужно контролировать. Иначе в коллекции появятся документы разных версий, а приложение начнет падать на старых данных
Вариант 1: Django MongoDB Backend
Если проект построен на Django MongoDB Backend, сначала проверьте, какие возможности поддерживает ваша версия backend. Для моделей и миграций используйте документацию backend и Django migrations
Обычный цикл:
python manage.py makemigrations
python manage.py migrateНо не переносите ожидания из PostgreSQL один в один. MongoDB — документная база, и часть решений по структуре документов все равно нужно продумывать отдельно
Вариант 2: MongoEngine
Если вы используете MongoEngine, модель в Python описывает документы, но изменение модели само по себе не переписывает старые документы в базе. Например, вы добавили поле status. Новые документы будут с ним, старые — без него
Тогда нужен скрипт:
from pymongo import MongoClient
client = MongoClient("mongodb://localhost:27017")
db = client["app"]
result = db.orders.update_many(
{"status": {"$exists": False}},
{"$set": {"status": "new"}}
)
print(result.modified_count)После запуска проверьте:
db.orders.countDocuments({ status: { $exists: false } })Ожидаемый результат — 0
Версия схемы документа
Для сложных проектов полезно хранить версию структуры:
{
title: "Заказ",
status: "new",
schemaVersion: 2
}Тогда миграция может обновлять только документы старой версии:
db.orders.updateMany(
{ schemaVersion: 1 },
{ $set: { schemaVersion: 2, status: "new" } }
)Как делать безопасно
Сначала сделайте резервную копию. Потом прогоните миграцию на тестовой базе. После этого запускайте на рабочей базе маленькими понятными шагами: добавить поле, проверить, обновить код, снова проверить
Если миграция тяжелая, не запускайте ее в момент пиковой нагрузки. Большие обновления могут заметно нагрузить базу
Частые ошибки
Думают, что гибкая схема отменяет миграции
Нет. Старые документы все равно нужно приводить к формату, который понимает новый код
Меняют модель, но не меняют данные
Код ожидает поле, а в старых документах его нет. Добавьте значение по умолчанию или миграционный скрипт
Не проверяют результат
После миграции считайте документы, которые остались в старом формате
Не делают резервную копию
Перед массовым updateMany нужна возможность откатиться
Что почитать дальше по MongoDB
Если нужен общий маршрут по теме, откройте рубрику MongoDB. Для соседних задач пригодятся эти разборы:
- Node.js и MongoDB: как правильно закрывать client.close
- Как правильно заполнить MongoDB через Mongoose
- Как правильно составить запрос в MongoDB
- Discord bot на Python и MongoDB: как задать проверку
Как проверить результат на практике
Для MongoDB-материала полезно делать три проверки: сначала выполнить команду на маленьком наборе тестовых документов, затем посмотреть результат через find() или MongoDB Compass, а после этого повторить действие на копии реальной структуры данных. Если запрос меняет документы, сначала запускайте его с фильтром на один документ и только потом расширяйте условие
Еще одна хорошая привычка — записывать исходное состояние и ожидаемый результат. Например: было три документа, после обновления изменился только один; был массив из пяти элементов, после операции остался нужный элемент; индекс появился в getIndexes(). Такая проверка быстро показывает, что вы исправили именно задачу, а не просто получили команду без ошибки
