Allow for a plugin architecture in jooq-meta, jooq-codegen, for custom schema-sources and generation-targets

[lukaseder]

Recent attempts of using CSV, XML files as a schema-source failed. Those formats are probably not general enough for common use-cases. Yet, such ideas are vital to the future of jOOQ, as users have many reasons not to generate source code directly from the database. One such reason is discussed in this thread here:

https://groups.google.com/d/topic/jooq-user/Pb-_c2CNwsY/discussion

Where the OP claims that their optimal code generation architecture is based on reading JPA annotations as a primary source of the database schema.

While this idea is nice, it is not immediately practicable in jOOQ (lack of many DDL features, such as compound PK's, triggers, indexes, foreign keys, etc. etc.)

With a plugin architecture, however, users can easily write their own logic, which suits their needs without supporting the full scope of jOOQ's SQL support.

Another option would be to switch to something like Xtend as suggested by Aaron Digulla here:

• https://groups.google.com/d/topic/jooq-user/dq4GFJv6oqs/discussion
• http://www.eclipse.org/Xtext/documentation.html#%23TutorialCodeGeneration

[lukaseder]

We might integrate XML schema input with https://www.vertabelo.com or similar tools:

• Out-of-the-box Vertabelo XML format integration #3789
• Add XMLDatabase to generate a database schema from an XML file #3451

[steveash]

I vote for this too. When it comes to the normal use cases for CRUD, I like leveraging hibernate's session cache. It is natural to create domain objects, pass them through components, let hibernate's session cache handle buffering updates, and then flush everything at once (allowing it to reorder things for jdbc batching and to resort things to be more "lock order" friendly to avoid deadlocks. This buffering, session management, and caching (both by PK and by natural key) are the features that I leverage for my day to day CRUD.

For "hard core" SQL Jooq is by far the right answer. Certainly the MERGE query support is a killer feature that hibernate just doesn't do. When I own the entire schema then I prefer using the JPA+Hibernate metadata as my "definition", because I want real pojos that I can have helper methods, control over equals/hashcode methods, etc. I use classes directly more than tables. If I use the DDL as the "definition" then I have to generate JPA pojos, which are always ugly. OR I have it defined twice, which is evil.

[lukaseder]

@steveash : This will certainly be useful to a lot of jOOQ+JPA users. I suspect, though, that the easiest way to go forward is to provide out-of-the-box support is to follow Vlad Mihalcea's idea of using an embedded database as an intermediary:

http://vladmihalcea.com/2013/12/06/jooq-facts-from-jpa-annotations-to-jooq-table-mappings

While reverse-engineering simple annotations like @Table or @Column is certainly easy, it will get quite tricky with @Embedded, @SecondaryTable, @Inheritance and all the more sophisticated annotations.

But instead of leaving the burden of setting up such an intermediary step to the user, it would be great if jOOQ could handle this out of the box.

[lukaseder]

Coincidentally, there's a related discussion about this on the user group right now:
https://groups.google.com/forum/#!topic/jooq-user/6Bl7QLF2t1U

[lukaseder]

jOOQ 3.5 introduced XMLDatabase. jOOQ 3.6 introduces a JPADatabase via the new jOOQ-meta-extensions project (which also includes the Vertabelo integration from #3789). This could be sufficient for now, as far as "code generator plugins" are concerned.

I prefer not to introduce too many mechanisms to do the same thing. The easiest way to supply meta information to the code generator is via jOOQ-meta's org.jooq.util.Database