Как лучше сделать файлы для миграций sql

Я так понял, ты какой-то свой велосипед пытаешься придумать? Почему не взять готовое?

А подскажите готовое для KX? Я потом это буду встраивать в job Jenkins

Тысячи их: https://lmgtfy.com/?q=sql+migration+tool

Хотя все они не без изянов. У меня свой велосипед, который делает толко migration-up. Обратно в общем случае пути всё равно нет, ибо потеря данных.

Просто для clickhouse тот же ruckus не умеет его . Насчет обратного там тока колонки убиратся , причем все в начале на деве теститься и потом только на прод выливается.

Интересует просто как это и где лучше сделано ? Интересует сам алгоритм

В моём велосипеде всё просто до безобразия. Табличка change_log с именем скрипта и датой на всякий пожарный.

И маленькая обёртка на Go, которая смотрит, есть ли уже данный скрипт в change_log и если нет запускает его в трансакции, в которой также дописывает строчку в change_log.

Тупо, просто, но надёжно.

Как уже говорил, работает только в одну сторону. Но это было обдуманное и желаемое решение.

change_log где хранишь ?

У каждой db свой, рядом со всеми остальными таблицами.

В виду чего сделал в одну сторону , ведь если не брать в расчет insert into … from … то все alter колумны и тд можно сбросить ?

Можно. Но зачем усложнять без надобности? Из преимуществ такого подхода:

• не надо поддерживать два вида миграций (а ведь писать down, сложнее чем up)
• линейная история
• простая имплементация с минимум тулинга, всё тоже можно и на чистом sql устроить
• если надо что-то убрать, то просто докидываешь ещё один скрипт
• скрипты никогда не меняются, т.е. append-only.

ок, понял . Но мне все же надо и с откатами

Нормально, только я бы писал логи рядом в базу (как flyway делает, например). Кстати, попробуй flyway, может, заведется через jdbc. А так сделал migration_up|down, накатил, записал в базу (migration_name, title, migration_file_hash), в следующий раз перед миграцией проверяешь, что хеши существующих миграций не изменились, накатываешь новое. Плюс хендлинг ошибок. Для down наоборот.

Прям вот чтобы из коробки был clickhouse, наверное ничего нет. Всё-таки слишком специфичная БД.

Я бы посмотрел на Liquibase, поддержки clickhouse там нет, но с JDBC драйвером должно заработать. Возможно придется немного пошаманить.

Оно не умеет clickhouse, также с наскока не завелось ( .

Да там придется много шаманить , к сожаления на это нет времени (

так ему и не нужно уметь кх специально, оно умеет jdbc. А sql вроде произвольный ест. Но в любом случае, глянь доки наискосок, понятно будет, как нормальные миграторы работают. Подели на 10 и напиши свой, легковесный.

скрипт на питоне на 100 строк: открыл коннекшен, открыл файл, открыл транзакцию, выполнил запросы, сохранил запись о файле, закоммитил транзакцию, закрыл файл, закрыл коннекшен.

для ch используем

https://github.com/golang-migrate/migrate

дак migration down это тупо drop + backup ddl крайний

Ну я так и сделал . У меня просто запускается в job e jenkis стоит

docker exec -t bk su www-data -s /bin/bash -c 'clickhouse-client -h clickhouse-server225 -u user --password XXXXX -q "$(cat < /migr123/up.sql )" '

И да у меня по сути ddl

Спасибо за ссылку !! А примерами как оно у вас сделано не поделишься ?

завернуто в ansible, порядок такой:

• пишешь up-down файлы
• через migrate version смотришь версию, если не соответствует делаем migrate goto

для Clickhouse

Мы форум поддержки Яндекса?

Нет, но там не помогли