Лучший способ для "специфичных для базы данных" sql-скриптов с Flyway

Я начал использовать Flyway в моем текущем проекте для миграции базы данных, и мне это очень нравится. В настоящее время я использую Oracle в PROD- и Derby в TEST-Environment.

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

ALTER TABLE T1 MODIFY F1 VARCHAR(256); в Oracle vs
ALTER TABLE T1 ALTER F1 SET DATA TYPE VARCHAR(256); в Derby.

Я не вижу способа написать "нейтральный вариант изменения дерева поставщика", sql. sql.

Какой лучший способ справиться с этой проблемой с помощью Flyway?

Ответ 1

Вы можете использовать свойство flyway.locations.

В тесте in будет выглядеть так:

flyway.locations=sql/common,sql/derby

и в prod:

flyway.locations=sql/common,sql/oracle

Затем вы могли бы иметь общие утверждения (V1__Create_table.sql) в общих и разных копиях спецификаций, специфичных для БД (V2__Alter_table.sql) в местах, специфичных для db.

Еще лучшее решение, на мой взгляд, состоит в том, чтобы иметь тот же БД в prod и test. Да, вы теряете немного производительности, но, с другой стороны, вы также устраняете еще одну разницу (и потенциальный источник ошибок) между средами.

Ответ 2

Различия в SQL между Oracle и некоторыми из этих настольных баз данных незначительны. Возможно ли, чтобы разработчик вставлял специальный код для выполнения легкого динамического удаления SQL во время выполнения на основе среды (например, удаление табличного пространства)?

Я предпочитаю этот подход полагаться на каждого разработчика, чтобы вручную синхронизировать два набора SQL.