How to always generate `Table` constructors for JOOQ 3.11's implicit-join feature? - code-generation

Question

JOOQ 3.11 introduced an awesome feature called implicit joins.
Unfortunately, the new feature causes trouble with our half-baked application modularization.
Symptom
Looking at the JOOQ generator source code, I found out that the following constructor for the generated class FileStorage (a Table subclass) are generated only if the JOOQ generator finds a foreign key referencing FILE_STORAGE:
public <O extends Record> FileStorage(Table<O> child, ForeignKey<O, FileStorageRecord> key) {
super(child, key, FILE_STORAGE);
}
This leads to compilation errors in our build that generates the JOOQ model for each application module separately:
We use one schema per application-module (e.g. billing) and one special schema shared that is visible from every application-module. The JOOQ metamodel for shared is generated in complete isolation from the rest, so during the code-generation for shared, a foreign key from INVOICE (module billing) to FILE_STORAGE (module shared) will not be visible to the JOOQ generator. Thus, the above constructor is missing on the FILE_STORAGE side but not on the INVOICE side of the JOOQ model and we end up with compilation errors in Invoice from billing's JOOQ model.
Question
Short of duplicating the JOOQ model for shared in 10+ application modules, is there any solution to this issue? Why aren't these constructors generated unconditionally?

Answer 1

The reason for the current implementation (jOOQ 3.10.0) is to prevent "excessive" code generation in cases where there are only few foreign key constraints in a large schema. I.e. there's only little gain in having this limitation.
The fact that there are compilation errors in generated code in your setup hints that this limitation is effectively wrong. It should be removed again from jOOQ 3.12.0 and 3.11.1:
https://github.com/jOOQ/jOOQ/issues/7573
A workaround could be to generate all schemas and remove the unwanted code using a post-processor.