Open tamaro-skaljic opened 1 year ago
Thanks a lot for your feature request. This idea pops up occasionally. So far, I've rejected implementing anything in this direction, because we already have all the means of influencing output layout via generator strategies, and that's where you should implement this.
I'm aware there's a lack of influence over the target directory on a per-Definition
basis, which I'll look into:
Other than that, the <database>
is a meta data source configuration and shouldn't have any elements of control for code generation. Think about it this way: the jOOQ-meta
module doesn't really know its main purpose is code generation, so target
doesn't make sense on the inputSchema
, even if that looks like you'd naturally place it.
But that's not fine grained enough for even more edge case-y use-cases, e.g. what if you only want to place 5 tables and 3 UDTs in a different directory? That's why the GeneratorStrategy
will be useful.
I'll retrofit this task to update the configurative <matchers>
strategy:
https://www.jooq.org/doc/dev/manual/code-generation/codegen-matcherstrategy/
See also related task:
Regarding your workarounds:
- Create a script that automatically moves the files to the desired directories after the JOOQ code generation and adjusts the package declarations.
Sure, why not. Pragmatism is often king with such edge cases.
- Create more than one code generator configuration and run the generator multiple times, violating the DRY principle at least in the case of XML/Groovy configuration (Maven, Gradle).
Maven allows for re-using common elements from a <pluginManagement/>
configuration, or even a plugin configuration that is shared among executions:
<plugin>
<!-- shared configuration -->
<configuration/>
<executions>
<execution>
<!-- Individual override -->
<configuration/>
</execution>
<execution>
<!-- Individual override -->
<configuration/>
</execution>
</executions>
</plugin>
This is also pragmatic. We do this all the time in integration tests, to override defaults globally.
I don't know Gradle well enough, but I'm sure you can re-use things as well there, given that it's just Groovy/Kotlin code? There's also programmatic code generation as an option: https://www.jooq.org/doc/latest/manual/code-generation/codegen-programmatic/
Anyway, I'll implement this for jOOQ 3.19
That way, at least in a programmatic GeneratorStrategy
, you can easily override the target directory per whatever your criteria. Starting with 3.19, we'll also allow for ad-hoc compilation of these programmatic GeneratorStrategy
implementations to simplify things:
Anyway, I'll implement this for jOOQ 3.19
I shouldn't promise such things 😅. Currently, we have a notion of a single file root, whose contents are completely managed by jOOQ (and thus deleted, if not re-generated). There are probably more things that get more complicated if we implement this and #15208. So I won't promise any target release.
The workarounds are perfectly fine for now.
Hi @lukaseder, thanks for your quick feedback and especially also for wanting to implement this - in whatever version.
That the database
tag could be the wrong place and the whole thing would then not be fine-granular enough, I almost thought, because I consulted other issues and the documentation before. But it was so far the only place where I saw something being configured by schema/catalog. Anyway, thanks for the explanation.
Special thanks for the paragraph on Maven plugin management - I had only dealt with the topic stepmotherly (a proverb for "worse than would be appropriate" in German) so far.
Use case
As a user I want to configure the output target of the code generator per catalog and schema. At the moment It's only possible to configure the output target once, at global level (see output target configuration).
I think this feature would also affect custom generator strategies.
Background:
Possible solution
(edit: Quote @lukaseder "Other than that, the
<database>
is a meta data source configuration and shouldn't have any elements of control for code generation.") Possible solution see hereExample xml configuration:
```xmlPossible workarounds
There are two possible workarounds:
OR
jOOQ Version
3.16.6
Database product and version
PostgreSQL
Java Version
No response
OS Version
No response
JDBC driver name and version (include name if unofficial driver)
No response