Jooq: Add configuration in DDLDatabase matching Settings.interpreterDialect

Created on 10 Jan 2018  路  12Comments  路  Source: jOOQ/jOOQ

The current DDLDatabase works in many cases where users do not use any vendor-specific features, by translating vendor-specific SQL (that can be parsed by jOOQ) into H2's dialect.

Unfortunately, this means that a couple of features are not available from code generation via DDLDatabase, including:

  • MySQL enum types
  • MySQL unsigned types
  • USE database commands and similar, which put the script into some context
  • Much more

The advantage of the current approach is that we can "easily" support incremental migration scripts, i.e. scripts of the type:

create table x (a int);
alter table x add (b int);
alter table x add constraint pk_x primary key (a);

If we were able to interpret the above DDL on a mini database implementation that incrementally modifies a meta model (preferably the jOOQ meta model, or the XML content), we could also support more vendor-specific features.

This has been implemented via a variety of tasks. The remaining things to do here is

Code Generation Functionality All Editions High Enhancement

Most helpful comment

There's an increasing number of people who would like to use the DDLDatabase but run into its H2-specific limitations because of how DDLDatabase is currently implemented. We should definitely prioritise this feature for jOOQ 3.12

All 12 comments

There's an increasing number of people who would like to use the DDLDatabase but run into its H2-specific limitations because of how DDLDatabase is currently implemented. We should definitely prioritise this feature for jOOQ 3.12

Hi, we are some of the "increasing number of people" who are running into the limitations of DDLDatabase with H2.

Is there any estimate for a release date for jOOQ 3.12?

Alternatively, is there a way to make the DDLDatabase use H2 1.4.199 instead of 1.4.197? This seems to add support for enums.

Is there any estimate for a release date for jOOQ 3.12?

We expect to release version 3.12 by the end of the month or early September.

Alternatively, is there a way to make the DDLDatabase use H2 1.4.199 instead of 1.4.197? This seems to add support for enums.

jOOQ's jooq-meta-extensions Maven module declares a dependency on H2 version 1.4.197. You can however declare a dependency in your own pom.xml against H2 version 1.4.199 and that is what should then. See also the section "Forcing a version" in the Maven documentation: https://cwiki.apache.org/confluence/display/MAVENOLD/Dependency+Mediation+and+Conflict+Resolution.

jOOQ 3.12 will depend on H2 1.4.199.

Great, thanks!

jOOQ's jooq-meta-extensions Maven module declares a dependency on H2 version 1.4.197. You can however declare a dependency in your own pom.xml against H2 version 1.4.199 and that is what should then

Possibly, you'll have to exclude our own transitive dependency explicitly.

@lukaseder are there any plans on making additional implementations of _adapters_ for datasources available? i.e. I assume you will have an H2 _adapter_ to be backward compatible, would you also plan to have additional adapters for let's say Postgres, MySQL, via Docker?

@berngp: I'm not quite sure what would be the use-case for this? Do you mean to spin up a throwaway Postgres database in test containers just for the code generator? Then yes, we have a feature request for this on our roadmap: #6551

@knutwannheden Does your current implementation solve this problem here? #8824

Depends on your definition of "solve" 馃槈 We will definitely be able to allow this syntax. But when using H2 dialect DDL, we will in the future probably also want to have the possibility to raise an error, as would be the case when running the script against a real database. But that is for the future.

OK, my definition (for now) is: Do our tests cover this case :)

No, not yet. At the moment neither the tests nor the implementation cover very much. But I think most things are in place to allow expanding both quite easily.

This turns out to be more difficult to implement than I initially thought. The fact that DDLDatabase will no longer extend AbstractInterpretingDatabase and H2Database, but AbstractMetaDatabase now, means:

  • That a few features are not yet available (e.g. foreign keys: https://github.com/jOOQ/jOOQ/issues/3521)
  • Case sensitivity works a bit differently
  • Data types are reported a bit differently (regression risk, e.g. https://github.com/jOOQ/jOOQ/issues/7202)
Was this page helpful?
0 / 5 - 0 ratings