Какова миграция Джанго?
Некоторое время я обдумывал эту концепцию, когда я начинаю новый проект django, он призывает меня применить миграцию:
# python manage.py runserver
Performing system checks...
System check identified no issues (0 silenced).
You have 13 unapplied migration(s). Your project may not work properly until you apply the migrations for app(s): admin, auth, contenttypes, sessions.
Run 'python manage.py migrate' to apply them.
зачем мне это делать? Кто-нибудь может дать краткое объяснение и простой случай использования migration?
РЕДАКТИРОВАТЬ: Я решил опубликовать этот вопрос, потому что я не видел подобного вопроса здесь на stackru, может быть, есть лучшее объяснение, чем это в документе.
2 ответа
Миграции - отличный способ управления изменениями схемы базы данных. Это имеет 2 основных преимущества (на мой взгляд):
1 - Если у вас есть несколько экземпляров приложения - разработка + производство является типичным минимумом, но потенциально может быть приложением, устанавливаемым другими (автономными или вместе с другими приложениями Django), миграции позволяют вам, разработчику, распространять схему базы данных изменения безопасным и контролируемым образом. Вы можете гарантировать, что любая актуальная версия вашего приложения (т.е. включая ваши последние модели баз данных) будет иметь действующую базу данных для соответствия. Таким образом, общий ответ заключается в том, что миграции решают весьма распространенную проблему относительно элегантным образом.
2 - В частности, как отмечалось в другом ответе, существуют начальные миграции, даже для совершенно нового проекта Django, касающегося пользователей и прав доступа. Любое приложение Django любого значения, которое я могу придумать, будет нуждаться в этих таблицах для функционирования - то есть, если вы не используете их, то, вероятно, вы не получите пользы от того, что Django может предложить в качестве основы. Включая миграции, вы, разработчик, можете решить, какую базу данных использовать (SQLite, MySQL, PostgreSQL и т. Д.) И где будет находиться эта база данных, и как только вы настроите эти параметры (как правило, в settings.py для проекта), миграция займет заботиться об остальном.
Эти миграции предназначены для моделей, которые Django создает по умолчанию, таких как пользователи, группы и разрешения.
Если вы не собираетесь их использовать, вы можете закомментировать эти приложения в своих настройках. В противном случае вам нужно запустить эти миграции, чтобы создать необходимые таблицы для вашего приложения.
Команда migrate принимает все миграции, которые не были применены (Django отслеживает, какие из них применяются, используя специальную таблицу в вашей базе данных, называемую django_migrations), и запускает их в вашей базе данных - по сути, синхронизируя изменения, которые вы внесли в свои модели, со схемой в базе данных.
Миграции очень эффективны и позволяют вам со временем изменять модели по мере разработки проекта без необходимости удалять базу данных или таблицы и создавать новые - он специализируется на обновлении вашей базы данных в реальном времени без потери данных. Мы рассмотрим их более подробно в более поздней части руководства, а пока помните трехэтапное руководство по внесению изменений в модель:
Измените свои модели (в models.py).
Запустите python manage.py makemigrations, чтобы создать миграции для этих изменений.
Запустите python manage.py migrate, чтобы применить эти изменения к базе данных.
Причина того, что существуют отдельные команды для выполнения и применения миграций, заключается в том, что вы фиксируете миграции в своей системе контроля версий и отправляете их вместе со своим приложением; они не только облегчают вашу разработку, но и могут использоваться другими разработчиками в производственной среде.