Есть такое задание, есть много миграций с чистым sql,

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

М... Куча граничных случаев видится. А зачем это надо?

лень это делать вручную постоянно, хочется автоматизировать хотя б частично если не полностью

Вопрос не только в как, но и в зачем. Чем тебя смущают нормальные атомарные осмысленные миграции?

а если их наплодится пару десятков , это уже менеджить будет тяжело

Тяжело менеджить — это когда несколько тысяч. И то не обязательно.

Что по-твоему включает в себя менеджинг?

ну потом надо посмотреть эти миграции например чтоб сделать, там черт ногу сломитт, логичнее, их компактить

Сделать что?

чтоб сделать новую например, мало ли для чего захочется их посмотреть(

зачем?

чтобы сделать новую миграцию старые не надо читать

не могу понятть, у вас разве так не делают чтоб не хранитть миллион скриптов миграций, раз в месяц хотя б их компактить, зачем хранить сколько

непонятно зачем

Зачем это делать?

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

У тебя у каждой миграции есть причина существования, как раз в таком виде должно быть нормально отслеживать этапы развития проекта. Если слепить в кучу — понять будет сложнее. Единственное где, как я вижу, может как-то помочь объединение — если есть какие-то фиксированные релизы и пользователям приложения нужно только в этот момент их накатывать на свои копии приложения. И то нет никакой проблемы накатить по очереди несколько миграций. А плодить их большими количествами, чтобы за раз приходилось много изменений одной и той же таблицы делать — это что должно в проекте происходить?

Кстати, а что ты предлагаешь делать с теми миграциями которые уже запомнила база

а тут кейс другой - миграции накатываются постоянно , поскольку это dwh-storage, и там постоянно меняется структура таблиц, какой смысл хранить эту историю, не особо ясно

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

Блин. Что за проект такой, что миграции постоянно накатываются?

Какой ты удивительный человек Что не вопрос, так другой кейс :)))

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

1. лишнее место? ну я даже не знаю 2. зачем в них рыться кроме как для того чтобы узнать что реально применялось? 3. чтобы склеивать миграции надо бытьуврененым что они потом применятся к любому инстансу

а какие могут быть проблемы с уверенностью в 3 пункте?

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

ну вот у тебя были три миграции 1,2,3. Сервер находится в состоянии 2. Ты их склеил, получил одну миграцию 0-3. Пытаешься применить, получаешь ошибку "БД в неизвестном состоянии"

сервер обычно всегда состоянии 3 если мы берем прод, си сд для этого и придумали

когда из бэкапа достанете, будет не в 3

А если релиз прошел неудачно и надо откатить?

ну думаю такие корнер кейсы учитываются, они ж не каждый день склеиваются