Частные проблемы использования django-evolution

Сегодняшний день для меня ознаменовался эпичной битвой с django-evolution. С различными неудобствами этого приложения мы в разработке сначала Куда Все Идут, а потом Афиши сталкиваемся уже довольно давно. Сегодняшний же случай наконец заставил меня перебороть лень и изложить эти проблемы для публики.

Должен, тем не менее, обязательно сказать, что не считаю django-evolution плохим средством, потому что знаю, что во многих сценариях использования он вполне справляется со своими обязанностями. Однако архитектурные особенности нашего проекта и наши рабочие привычки, видимо, совмещаются с ним плохо. Поэтому принимайте текст как есть, без далеко идущих выводов, просто к сведению.

Очерёдность с syncdb

Одно из выбранных решений django-evolution — невмешательство в дела команды syncdb. То есть, django-evolution никогда не пытается выполнять SQL код для создания таблиц.

Первое неудобство в этом для нас — более сложный процесс составления миграционного SQL'а. Дело в том, что наши админы не шибко любят запускать изменения в базах всякими неконтролируемыми тулзами, а просят присылать им SQL-скрипты. Django-evolution умеет генерить SQL своих эволюций, а SQL для создания таблиц приходится вырезать руками из базы отдельно.

Но гораздо хуже другое. Представьте, что в процессе миграции базы с достаточно старой версии есть и новые модели, и эволюции, применяемые к этим моделям. Поскольку создавать таблицы надо отдельной командой, надо помнить, что этот SQL должен обязательно идти до эволюций. Несколько муторно. Теперь представьте, что среди эволюций есть переименование одной таблицы (соответствующее переименованию модели). С точки зрения syncdb таблицы для нового имени модели нет, и она её создаст. От этого эволюция переименования накроется, потому что таблица уже существует.

Приехали — есть эволюции, которые надо запускать до syncdb, а есть те, которые после. Соответственно, процесс превращается в совсем ручной cherry-picking.

Были ещё какие-то частные случаи, когда важен порядок применения syncdb и evolve, и в итоге, чтобы избавиться от этих проблем, мы стали вносить создания таблиц в эволюции вручную.

Написание симуляций

Кто не знает, в django-evolution есть интересная фича: она умеет не применять эволюции непосредственно к базе, а прогнать их сначала вхолостую ("simulate" в терминах приложения). Делается это не реально в БД, а спомощью выполнения специально написанных функций, которые меняют сигнатуру проекта — представление текущего вида моделей в памяти. Это примерно такой словарик:

{
    'myapp': {
        'MyModel1': {'fields': [ ... ], 'meta': [ ... ]},
        'MyModel2': {'fields': [ ... ], 'meta': [ ... ]},
    }
}

Идея состоит в том, что django-evolution берёт сохранённую сигнатуру из БД, которая соответствует предыдущему её состоянию, и протаскивает её через симуляционные функции всех неприменённых эволюций. Они меняют сигнатуру в памяти, и если в конце она соответствует тому, какая у вас модель в Питоне сейчас описана, django-evolution рапортует, что наличествующих эволюций достаточно для того, чтобы проапгрейдить базу.

Это хорошо работает в теории, если всю эту симуляцию делает за вас миграционное приложение. Однако на практике выходит так, что кроме обычных эволюций типа добавить поле/удалить поле у нас очень немало кастомных эволюций. Создания таблиц, переименования таблиц, разделения таблиц на несколько и т.п. Получается, что на каждый такой кастомный чих надо писать два кода: реальный SQL и симуляцию.

Хуже того, многие симуляции нужны только для того, чтобы evolve перестал жаловаться на несовпадение при симуляции, потому что в этом случае он отказывается что-либо делать вообще. Ни применить эволюции, ни SQL для них вывести. Нет у него ключика --force...

В качестве грустного примера могу привести эволюцию "DeleteFieldWithoutSQL", которая нужна для того, чтобы симуляция показала, что поле из модели удаляется, но при этом чтобы оно не удалялось физически, потому что позднее мы перетаскиваем данные из него в другую таблицу, и только потом удаляем.

В итоге по факту оказывается, что ещё не было ни одного релиза у нас, когда бы мы не тратили немало времени на то, чтобы дописывать код только для того, чтобы evolve хотя бы просто запускался поверх довольно старой версии БД. То есть по очереди во время разработки всё вроде применилось, а вот скопом — нет.

Hint'ованные и сохранённые эволюции

Эволюции можно применять двояко. Можно попросить автоматически определить текущую разницу между кодом и базой (--hint) и тут же её применить. А можно сохранить эволюцию в файл и зарегистрировать её в последовательности применения, чтобы она была применена при апгрейде другой БД.

Теперь представьте себе вполне обычный workflow:

• разработчик делает изменения в модели
• через evolve --hint -x отражает его в БД
• тестирует, отлаживает

Теперь, чтобы это скоммитить, надо обязательно записать проведённые эволюции в виде файла, чтобы автоматически апгрейдить другие БД. А откуда вы теперь эти эволюции возьмёте? Всё ведь уже применено.

Казалось бы, можно ввести в процесс разработки правило, что никогда нельзя применять hint'ованные эволюции, а делать их только в виде файлов. Но во-первых, слишком много таких "гигиенических" правил сильно нагружают голову, а во-вторых это просто не работает. Потому что не родился ещё тот разработчик, который бы с первого раза писал правильный код, в том числе и при изменении схемы БД. Всегда нужно что-то переделать по результатам отладки.

В итоге это тоже вечная война: или копайся, в кишках таблиц django-evolution, вручную вычищая информацию о применённых эволюциях, или убирай вручную изменения в базе и делай новую эволюцию.

Наличие двух видов эволюций мне сейчас кажется, пожалуй, главным архитектурным изъяном django-evolution. Хотя может быть, мы просто не поняли, как этим пользоваться...

Ключик "всё хорошо"

Обратная ситуация тоже частенько случается: у вас есть некая база, в которой что-то переделано вручную, что-то откуда-то сдамплено/скопировано. Однако программист уверен, что она соответствует тому, что есть в моделях. А команда evolve — нет. Потому что в базе не записано, что были применены сохранённые эволюции, она пытается их симулировать и находит ошибки от повторного применения.

К сожалению, у команды evolve нет никакого ключика, чтобы сказать базе: "всё применено руками, просто запиши новое состояние и считай, что все эволюции применены". Да, считается, что при использовании django-evolution нельзя лезть в БД руками. Но я поверю в практичность такого подхода, когда оно само будет работать идеального. А пока реальность такова, что в базу приходится лазить руками.

Не фиксируются отдельные эволюции

Даже для многих админов БД является откровением, что PostgreSQL умеет делать DDL в транзакциях. Ни одна другая СУБД из набора Джанги этого не умеет, даже Oracle. И надо ж случиться такому совпадению, что ядрёныекорные разработчики Джанги предпочитают именно Postgres. Рассел (автор django-evolution), кажется, тоже его предпочитает. Никак иначе я не могу объяснить то, что применяемые эволюции фиксируются как выполненные только по успешному завершению всей последовательности эволюций.

Представьте себе теперь типичную ситуацию выезда в продакшн на MySQL-сервере какой-нибудь напряжённой итерации разработки. Применямых эволюций там — десяток. И на разработческой базе они прекрасно применялись. А вот на живы данных — упали. Где-то в середине. С Postgres'ом бы не было проблем, транзакция бы не скоммитилась. Но у нас вот часть изменений применилась, а часть нет. Какая именно часть применилась, django-evolution в БД не записал. И теперь, если начать миграцию заново, оно будет пытаться применять уже применённые вещи, и напарываться на всякие "already exists" для создаваемых полей и "not exists" для удаляемых.

Если бы это действительно происходило в продакшне, то да, вы в ж... живописно чудовищной ситуации. Поэтому мы обычно перед выкладкой закатываем свежую продакшн-базу на тестовый сервер и имитируем там весь процесс выкладки. И поэтому же наши админы предпочитают работать с простым набором SQL-команд, а не с излишне автоматическими тулзами.

Эволюции лежат в приложениях

Считается, что эволюции относятся только к моделям одного приложения. Однако бывают эволюции, когда надо перетащить модельку из одного приложения в другое, например после рефакторинга, в результате которого второе приложение и возникло. Непонятно, куда класть такую эволюцию.

Еще одна (совсем специфичная для нас) проблема возникает от того, что у нас два разных проекта живут на одной базе и используют одно общее приложение и свои собственные приложения, про которые другой проект не знает. Когда один проект применяет эволюции для себя, django-evolution записывает в базу сигнатуру этого проекта. В последствие, когда другому проекту надо применить эволюции своих приложений, он напарывается на сигнатуру, в которой нет его приложений вообще, зато есть какие-то левые другие.

Поэтому нам хочется иметь эволюции, относящиеся к какой-то конкретной базе, и лежащие где-то отдельно от структуры приложений.

Что вместо?

В связи с вышеизложенным мы, накушавшись, хотим попробовать что-то другое.

Видимо, это будут dmigrations. Миграции там хранятся в отдельной директории, применяются только из сохранённых файлов, и там есть ручной контроль — команда mark_as_applied. Очень похоже, что их авторы исходили из очень практических use-case'ов и наступали на похожие с нашими грабли.

South решили не пробовать. Саша утверждает, что он "ещё хуже", чем django-evolution :-). А остальным разработчикам, включая меня, кажется, должно быть всё равно, потому что не работали ни с South, ни с dmigrations.

Посмотрим, что получится.