Глава 22 · Веб-разработка с Python

Миграции схемы базы данных

Структура таблицы меняется вместе с приложением — миграция записывает это изменение предсказуемо.

Слово «миграция» в веб-разработке означает две разные вещи, и их легко перепутать. Эта страница — про первую: миграцию схемы — изменение структуры базы данных со временем. Вторая — перенос самих данных между базами — рассматривается в разделе 22.28.

Приложение растёт, и структура таблицы, спроектированная в начале, перестаёт хватать. Например, у задачи появляется отметка «выполнено»:

Миграция схемы — это записанное изменение структуры, которое можно применить к базе данных так же предсказуемо на любом компьютере: у разработчика локально, у коллеги, на сервере. В SQL для этого есть команда ALTER TABLE:

ALTER TABLE tasks ADD COLUMN done INTEGER NOT NULL DEFAULT 0;

Старые строки не исчезают — у каждой из них новый столбец done получает значение по умолчанию, 0.

import sqlite3

baza = sqlite3.connect("zadachi.db")
baza.execute("ALTER TABLE tasks ADD COLUMN done INTEGER NOT NULL DEFAULT 0")
baza.commit()

Инструменты, которые записывают миграции за вас

В маленьком проекте достаточно выполнить ALTER TABLE вручную один раз. В более крупном проекте с несколькими разработчиками и несколькими окружениями миграции обычно оформляют отдельными файлами с номерами и порядком применения — чтобы каждое изменение структуры можно было применить, отследить и, если нужно, откатить. В экосистеме SQLAlchemy для этого используют Alembic — отдельный инструмент для миграций схемы, который умеет сравнивать текущую структуру базы с описанием в коде и формировать черновик миграции; такой автосгенерированный файл — не готовое решение, а «черновая миграция» (candidate migration), которую нужно проверить и при необходимости поправить вручную перед применением. В Django миграции встроены в сам фреймворк: команда makemigrations создаёт файлы миграций по обнаруженным изменениям моделей, а migrate применяет их к базе данных.