Как всегда генерировать конструкторы `Table` для функции неявного соединения в JOOQ 3.11? - PullRequest
0 голосов
/ 11 июня 2018

В JOOQ 3.11 появилась потрясающая функция, называемая неявные объединения .

К сожалению, новая функция вызывает проблемы с модульной модульностью нашего приложения.

Симптом

Просмотр исходного кода генератора JOOQ, я обнаружил, что следующий конструктор для сгенерированного класса FileStorage (подкласс Table) генерируется, только если генератор JOOQ находит внешний ключ, ссылающийся на FILE_STORAGE:

public <O extends Record> FileStorage(Table<O> child, ForeignKey<O, FileStorageRecord> key) {
    super(child, key, FILE_STORAGE);
}

Это приводит к ошибкам компиляции в нашей сборке, которая генерирует модель JOOQ для каждого прикладного модуля в отдельности:

Мы используем одну схему для каждого прикладного модуля (например, billing) и одну специальную схему shared, видимую изкаждый прикладной модуль.Метамодель JOOQ для shared создается в полной изоляции от остальных, поэтому во время генерации кода для shared внешний ключ от INVOICE (модуль billing) до FILE_STORAGE (модуль shared)не будет виден генератору JOOQ.Таким образом, вышеприведенный конструктор отсутствует на стороне FILE_STORAGE, но не на стороне INVOICE модели JOOQ, и мы получаем ошибки компиляции в Invoice из billing модели JOOQ.

Вопрос

Если не считать дублирования модели JOOQ для shared в модулях 10+ приложений, есть ли какое-либо решение этой проблемы?Почему эти конструкторы не генерируются безоговорочно?

1 Ответ

0 голосов
/ 12 июня 2018

Причина текущей реализации (jOOQ 3.10.0) состоит в том, чтобы предотвратить «чрезмерную» генерацию кода в случаях, когда в большой схеме есть только несколько ограничений внешнего ключа.То есть есть только небольшое преимущество в использовании этого ограничения.

Тот факт, что в сгенерированном коде в вашей установке есть ошибки компиляции, намекает на то, что это ограничение фактически неверно.Его следует снова удалить из jOOQ 3.12.0 и 3.11.1:

https://github.com/jOOQ/jOOQ/issues/7573

В качестве обходного пути можно было бы сгенерировать все схемы и удалить нежелательный код с помощью постпроцессора.

...