Здравствуйте,
есть БД на PostgreSQL, в ней хранятся данные (много, но не очень, 20Гб). В ней относительно много бизнес-логики - процедуры, триггеры, представления (в том числе материализованные) и код этого всего весьма нетривиален, включая парсинг xml запросами xpath и прочую магию, соответственно все это густо покрыто тестами pgTAP.
В конце концов возникла задача как бы схему хранить в репозитории и иметь возможность ее деплоить в рабочую или staging базу.
Итак, как я пытался решить эту задачу:
- Так как в базе, внезапно, данные, требуется изменять схему при помощи миграций. Решено было использовать Flywaydb
- Часть схемы не ложится на формат миграций, например, те же хранимки, их удобнее раскидать по каталогам и там при необходимости редактировать
- Соответственно, чтобы заставить Flywaydb их накатывать, подумал рассматривать миграции как артефакт сборки, подумал при помощи gradle (все равно уже нужна java для flyway) конкатенировать outOfDate файлы в миграции и добавлять в отдельную папочку с генерированными миграциями
Однако здесь возникло большое НО: при разработке придется править хранимки до прохождения ими тестов, это приведет к большому количеству лишних миграций которые я не знаю как можно автоматически вычистить, в результате будет опять же помойка в репозитории.
Конечно приходит в голову решение разделить сборку для development сервера (просто из gradle накатывать sql файлы при помощи pgadmin) а для фиксации изменений в миграции использовать означенный выше механизм, но хотелось бы для начала узнать как другие решают эту проблему.