В 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+ приложений, есть ли какое-либо решение этой проблемы?Почему эти конструкторы не генерируются безоговорочно?