Как организовать структуру проекта на PostgreSQL?

Здравствуйте,

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

Однако здесь возникло большое НО: при разработке придется править хранимки до прохождения ими тестов, это приведет к большому количеству лишних миграций которые я не знаю как можно автоматически вычистить, в результате будет опять же помойка в репозитории.
Конечно приходит в голову решение разделить сборку для development сервера (просто из gradle накатывать sql файлы при помощи pgadmin) а для фиксации изменений в миграции использовать означенный выше механизм, но хотелось бы для начала узнать как другие решают эту проблему.
  • Вопрос задан
  • 647 просмотров
Пригласить эксперта
Ответы на вопрос 1
evtuhovich
@evtuhovich
Консультант
Был похожий вопрос здесь, там есть ответ Как контролировать хранимые процедуры и тригеры через VCS?
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы