PgSQL: git-миграции
Статус документа: черновик
Задача
Найти способ разместить хранимый код в файлах так, чтобы его изменения были доступны через git, т.е. придумать миграцию, в которой изменения как можно большей части SQL будут в тех же файлах
Условия
- речь идет, прежде всего, о PostgreSQL
- конструкция
CREATE OR REPLACE {FUNCTION|VIEW}позволяет обновить код без потери функциональности кода, использующего эти объекты - тест хранимого кода внутри транзакции, вызвав EXCEPTION, отменяет все изменения
Базовые идеи
- файлы с миграциями разделить на 2 группы
1.1. создание таблиц с важными данными, которые не должны удаляться без запроса на удаление схемы
1.2. вспомогательные объекты, которые могут быть пересозданы внутри транзакции (например - справочники) - SQL-запросы поместить в файлы, которые исполняются
2.1. однократно (создание таблиц и их изменение)
2.2. при каждой миграции (создание/обновление функций и представлений + тесты) - Для файлов однократного выполнения считать контрольную сумму, сохранять ее в БД и при следующих запусках проверять ее неизменность
- SQL удаления объектов сохранять в БД с привязкой к файлу
Вариант решения
- разбить БД на схемы данных, инкапсулирующих связность (чтобы миграция затрагивала минимум схем)
- в каждой схеме выделить файлы, содержащие только SQL из п. 2.1 - у них маска *_once.sql, при выполнении в БД сохраняется их контрольная сумма (если изменятся - будет предупреждение или прерывание миграции)
- зафиксировать имя, которое при сортировке файлов разделит список на 2 части
3.1. корневая - когда надо удалить всю схему
3.2. вторичная - то, что можно удалить без потери данных корневой - для каждого файла предоставить ф-ю с аргументом - SQL удаления созданных объектов, чтобы его сохранили и выполнили по команде “удалить файл”
Какие плюсы
- Для SQL-разработчиков получим обычную среду разработки
В чем сложности
- Если меняется сигнатура функции, ее надо сначала удалить - нужен алгоритм, как это разруливать
- Удаление и повторное создание внешних ключей хоть и делаются внутри транзакции, могут не получиться из-за dead-lock на нагруженной БД