Matcher strategies should allow for overriding target directory

tamaro-skaljic commented 1 year ago

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:

I made the strategic decision that the generated code is part of the codebase and therefore under version control. I currently have a Maven Multi Module project (monorepo) where in production each module is a separate microservice with its own database. However, to improve the development experience, a single code base with a single database exists in the development environment. So in production, each schema in the development database is in its own database server.

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 here

Example xml configuration:

```xml catalog schema1 com.example.schema1.data.db src/main/java/com/example/schema1/data/db schema2 com.example.schema2.data.db src/main/java/com/example/schema2/data/db UTF-8 en true ```

Possible workarounds

There are two possible workarounds:

Create a script that automatically moves the files to the desired directories after the JOOQ code generation and adjusts the package declarations.

OR

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).

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

lukaseder commented 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:

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

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:

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

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

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

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:

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

lukaseder commented 1 year ago

Anyway, I'll implement this for jOOQ 3.19

Add GeneratorStrategy.getTargetDirectory(Definition, Mode) #15260

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.

tamaro-skaljic commented 1 year ago

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.

jOOQ / jOOQ