The jOOQ User Manual Code generation Code generation and version control

previous : next

Code generation and version control

Applies to ✅ Open Source Edition   ✅ Express Edition   ✅ Professional Edition   ✅ Enterprise Edition

When using jOOQ's code generation capabilities, you will need to make a strategic decision about whether you consider your generated code as

• Part of your code base
• Derived artefacts

In this section we'll see that both approaches have their merits and that none of them is clearly better.

Part of your code base

When you consider generated code as part of your code base, you will want to:

• Check in generated sources in your version control system
• Use manual source code generation
• Possibly use even partial source code generation

This approach is particularly useful when your Java developers are not in full control of or do not have full access to your database schema, or if you have many developers that work simultaneously on the same database schema, which changes all the time. It is also useful to be able to track side-effects of database changes, as your checked-in database schema can be considered when you want to analyse the history of your schema.

With this approach, you can also keep track of the change of behaviour in the jOOQ code generator, e.g. when upgrading jOOQ, or when modifying the code generation configuration.

The drawback of this approach is that it is more error-prone as the actual schema may go out of sync with the generated schema.

Derived artefacts

When you consider generated code to be derived artefacts, you will want to:

• Check in only the actual DDL (e.g. controlled via Flyway)
• Regenerate jOOQ code every time the schema changes
• Regenerate jOOQ code on every machine - including continuous integration

This approach is particularly useful when you have a smaller database schema that is under full control by your Java developers, who want to profit from the increased quality of being able to regenerate all derived artefacts in every step of your build.

The drawback of this approach is that the build may break in perfectly acceptable situations, when parts of your database are temporarily unavailable.

Pragmatic combination

In some situations, you may want to choose a pragmatic combination, where you put only some parts of the generated code under version control. For example, you may want to version control your POJOs, but not your tables / records. This can be achieved in multiple ways:

• You could use a generator strategy to relocate your POJOs to a different package, making excluding one or the other artifact using e.g. .gitignore much simpler
• You could run the code generator twice, once for POJOs only, and once for the rest.

The jOOQ User Manual Code generation Code generation and version control

previous : next