ШТА?
нужно построить дерево ривизий на питоне
Порядок миграций задается метаданными (ссылками на родительские миграции)
скорее их нужно расположить так чтоб апгрейд и даунгрейд всегда был коректным. На данный момент у нас это делается по хрологии
пытались делать поиск в ширину, поиск в долготу, оба варинта не работают, хронологический вроде норм
там внутри каждого файла ж апргейд и даунгрейд, и алембик сам умеет порядок понимать
Там внутри каждого файла список родительских ревизий ты хотел сказать
Внутри каждого файла id этой ревизии и id предыдущей. Если вы такие крутые в разных бранчах наделали своих ревизий и потом смержили — алембик не будет порядок понимать.
Звучит как базовый функционал https://alembic.sqlalchemy.org/en/latest/branches.html#merging-branches
Угу, история в алембике это ациклический граф, прямо как в гите
а в чём вообще прикол, почему эти миграции деревом? и почему не было задачи переделать чтобы линейно шли?
монорепа. десятки людей работают. Могут быть несколько миграций от одного родителя , потому что два чела одновременно создали
так блин это же на мерже надо разруливать
это постоянно лишнее время, такое постоянно случается
???? я понятия не имею нахрена на этом экономить
команда работает не одна а много, тяжло понять с кем разруливать, любой чловек по сути может одновременно с тобой решит сделать а ты не знаешь
а миграции в нескольких репах что ли?
Мы у себя когда делали тестирование миграций, для каждой миграции накатывали все предыдущие, затем инициализировали данные, накатывали тестируемую и запускали тесты, затем downgrade и снова тесты.
А архитектора базы у вас тупо нет, наверное...
а зачем нужен архитектор базы если наша бд юзатся сугубо для хранения данных что ровно так как они хранятся и отображаются в приложении
миграции все в 1 репе, монорепа. Да на похер мержим, ведь алембик умеет с этим справлятся
Обсуждают сегодня