Блог

Одна из проблем, которой я хотел бы избежать, — это две ветви, обновляющие сгенерированный JOOQ код. Я полагаю, что это может привести к беспорядочному конфликту слияния. Существует ли передовая стратегия для управления изменениями БД в двух разных ветвях с помощью JOOQ?

Будущая поддержка нескольких версий схемы jOOQ

Генерация кода с несколькими версиями схемы появится в следующем выпуске с https://github.com/jOOQ/jOOQ/issues/9626

Работа над необходимой инфраструктурой для вышеупомянутого началась в jOOQ 3.15. Предстоит много работы и открытых вопросов, но в конечном итоге можно будет определить набор исходных схем, которые все должны поддерживаться одновременно:

• Путем генерации кода
• По времени выполнения (например * , включает только столбцы, доступные в данной версии)

Создание собственного кода с использованием представлений SQL

До тех пор вы, возможно, сможете самостоятельно создать уровень совместимости, используя представления. Например:

 -- Version 1
CREATE TABLE t (
  id INT PRIMARY KEY,
  col1 TEXT,
  col2 TEXT
);

-- Version 2
CREATE TABLE t (
  id INT PRIMARY KEY,
  -- col1 was dropped
  col2 TEXT,
  -- col3 was added
  col3 TEXT
);
 

Теперь разверните представление, которое выглядит одинаково для вашего клиентского кода для обеих версий:

 -- Version 1
CREATE OR REPLACE VIEW v (id, col1, col2, col3) AS
SELECT id, col1, col2, NULL
FROM t;

-- Version 1
CREATE OR REPLACE VIEW v (id, col1, col2, col3) AS
SELECT id, NULL, col2, col3
FROM t;
 

Если ваша СУБД поддерживает обновляемые представления, вы можете использовать их как любую другую таблицу, особенно при добавлении синтетических первичных ключей / синтетических внешних ключей к вашему сгенерированному коду.

С помощью стратегии генератора вы можете дополнительно переименовать сгенерированные имена представлений V в T (при условии, что вы исключаете фактическое T из сгенерированного), и ваш клиентский код даже не заметит, что вы эмулировали T таблицу с помощью представления.