В Rails миграции это просто тонкая обёртка над SQL-кодом: добавь такой-то столбец, удали такой и т.д. Все миграции хранятся в одной папке в хронологическом порядке. Движок определяет, какие миграции прошли, на основе того, есть ли отметка о данной миграции в специальной служебной таблице в базе данных.
В Django тоже есть аналогичная таблица, но этим дело не заканчивается. Во-первых, миграции разделены по "приложениями" (см. выше). В каждом приложении хранятся миграции (по конвенции), касающиеся моделей этого приложения. Вместо подразумеваемой цепочки зависимостей из Rails (где мы, фактически, считаем, что каждая миграция зависит от всех по времени более ранних), в Django в начале каждой миграции явно указывается, от каких предыдущих она зависит (они могут быть из других "приложений"). Получается сложный граф зависимостей.
Представим, что во время рефакторинга мы удалили некое "приложение" или два "приложения" объединили в одно. Что происходит с миграциями? Происходит, как можно догадаться, fuck up beyond all repair. Вам придётся либо оставить миграции в покое (удалив из устаревшего "приложения" все другие файлы), либо переписать все миграции, фактически, с нуля. Элегантному фреймворку – элегантные решения.
Далее важно понять, что в Django миграции это не простые прямолинейные команды для движка. Это декларация о том, что должно быть в базе данных. Когда мы пишем в миграции А "добавить столбец X, Y", а в миграции B (следующей по времени позже A) "добавить столбец Z, удалить столбец X", движок (во время исполнения миграций, когда он считывает все файлы) понимает: "ага, у нас в базе сейчас столбцы Y, Z" (важно отметить, что к базе данных при этом он подключается только для получения списка уже сделанных миграций – если вы там сами что-то наворотили отдельно, то всё сломается).
Django формирует, на основе виртуального суммирования всех миграций, некое своё (точное) представление о том, какая сейчас структура в БД (исходя из того, что она создавалась исключительно миграциями). Это называется State, "состояние".
Затем Django доходит до миграций, которые ещё не были выполнены, и выполняет соответствующие SQL-инструкции (database operations). Здесь операция вроде "добавить столбец M" выступает уже в двух ролях:
– во-первых, как database operation (аналогично Rails) – инструкции буквально выполнить
ALTER TABLE...
– во-вторых, как state operation – инструкции обновить "внутренний образ" того, какая у нас текущая структура базы данныхКак можно было предполагать, этот изящный подход к проблеме от, как складывается впечатление, какого-то победителя региональных олимпиад по computer science, в реальных приложениях работает отлично 80% времени. Оставшиеся 20% времени вам потребуется, вырывая волосы на голове, вгрызаться в (довольно сложный, но всё же за пару дней можно разобраться) DSL миграций и писать миграции типа SeparateDatabaseAndState (это когда вы буквально говорите Django, мол, я сам в базе произведу нужные операции, не надо "читать мысли", а потом отдельно ещё ему объясняете для этого "внутреннего образа схемы БД", что же вы сделали).
Тема миграций напрямую связана с темой моделей. Модели в Django требуют явного указания полей (похоже на gem DataMapper), в то время как в Rails поля подгружаются в рантайме из базы данных. Явное указание полей модели позволяет делать "автомиграции" – написать команду, которая (в соответствии с теми изменениями, что вы внесли в моделях, сравнивая их со State, который был вычислен из предыдущих миграций) сгенерирует миграцию, в которой удаляются (добавляются, изменяются) соответствующие поля. Это издевательски небольшая, но иррационально приятная компенсация за все прочие мучения.
#programming #django