Какое ваше любимое решение для управления миграциями баз данных в django?
Мне очень нравится система управления миграцией баз данных Rails. Он не идеален на 100%, но помогает. Django не поставляется с такой системой миграции базы данных (пока?), Но есть ряд проектов с открытым исходным кодом для этого, например, django-evolution и south.
Мне интересно, какое решение для управления миграцией базы данных для django вы предпочитаете? (пожалуйста, один вариант ответа)
Ответы 8
Мне нравится джанго-эволюция:
плюсы:
- чистый дизайн
- SQL не нужен
- гибкий
- тривиально установить
- легко использовать
минусы:
- миграции не фиксируются в кодовой базе
- существует риск случайного запуска миграции дважды
Я не думаю, что в обычном рабочем процессе возможно выполнить миграцию дважды. Когда я запускаю manage.py evolve --hint --execute, он применяет изменения, повторный запуск ничего не дает.
Мигрирующий выглядит красиво и просто.
По состоянию на сентябрь 2010 года Migratory кажется мертвым. Ни один исходный код не фиксируется с января 2009 года, и он ожидает от Django того, чего больше нет в последней версии.
Мы используем Django в работе, и мы использовали переселение. Хотя у него есть свои причуды, до сих пор он был полезен. Некоторые особенности:
- Он использует таблицу в базе данных, чтобы отслеживать, какие миграции были применены.
- Поскольку он знает, какие из них были применены, вы можете выполнять миграцию вверх и вниз.
- Он интегрируется с
manage.pyкак команда. - Отдельные сценарии миграции - это Python, но если ваша логика миграции представляет собой чистый SQL, переселение упрощает использование SQL и его выполнение.
Одна проблема в том, что в настоящее время он поддерживает только MySQL. Однако один из наших ребят сделал локальный взлом для поддержки PostgreSQL, который мы используем. Насколько я помню, хакер был не таким уж масштабным, так что взломать его для поддержки других СУБД не должно быть очень сложно.
Я использовал юг, но Мигрирующий тоже выглядит многообещающим.
Помимо South, dmigrations, django-evolution и Migratory, я подумал, что добавлю простые миграции в качестве еще одного инструмента, который я видел для автоматизации миграции Django.
Раньше я использовал три из них, но сейчас выполняю миграции вручную. Я думаю о том, чтобы снова попробовать Юг из-за последних добавленных функций.
Просто отметим, что с 2009 года практически все упомянутые здесь проекты, кроме South, мертвы. юг является стандартом де-факто, хорошо это или плохо.
В течение некоторого времени у South не было никаких обновлений, и ссылка, которую вы разместили для их домена, не работает. Вы все еще считаете это стандартом де-факто?
@cwadding Нет, я бы считал встроенные миграции Django стандартом.
Что, если бы вы не создавали приложение Django, а просто нуждались в ORM и миграции? Вы бы по-прежнему использовали встроенные миграции Django?
@cwadding Миграции предназначены для ORM.
Я использовал простой-БД-миграция
Плюсы:
- это позволяет мне откатить миграции (IDK, если это делают другие).
- интегрируется с manage.py
- каждый, кто знает SQL, может создать миграцию
- он не выполняет миграцию дважды: приложение записывает информацию о миграции (временную метку, запрос и т. д.) в таблицу
Минусы:
- если вы добавите миграцию с более низкой меткой времени, чем последняя установленная миграция, эта миграция не запустится
- Поддерживается только MySQL
Если вы используете SQLAlchemy в качестве ORM, то стандартом де-факто является Перегонный куб.
Другая альтернатива, о которой не упоминалось, - это йойо-миграции.
Django поставляет инструмент миграции начиная с версии 1.7. Хотя, похоже, есть и другие, такие как простой-БД-миграция, ведущая альтернатива, юг, теперь указывает на встроенный инструмент миграции Django.