Hello Rakesh,

Something similar was recently requested by another user. I have CC'ed
my reply to Sergey on the user group:
https://groups.google.com/forum/#!topic/jooq-user/4-iZMVDtkGA

In principle, I do think that DDL and DML are entirely different
domains, in a way that I currently don't want to invest too much
effort in enhancing DDL support. With indexes, constraints, storage,
UDT's / UDF's, partitioning and many other DDL features, I don't think
I can easily cover the full feature-set of all 12 supported databases.
What I think would add true value to jOOQ, however, is support for
meta-data navigation through plugins and XML parsing:
https://sourceforge.net/apps/trac/jooq/ticket/875

That way, jOOQ code generation can become database-agnostic and connection-less.

> JOOQ should come with a database schema version tool.
>
> http://migrate4j.sourceforge.net/ seems simple and promising but current
> state is dormant in terms of DB support.
>
> https://github.com/azomazo/migrate4j has more databases supported and seems
> workable.

I'm always interested in concrete success stories. Migrate4j, however,
doesn't look very active to me:
https://github.com/azomazo/migrate4j/commits/master

This one looks more promising:
http://www.liquibase.org/

> This would overcome following disadvantage of JOOQ,
> "When you need to write DDL statements. jOOQ only supports DML statements."

I don't see this as a disadvantage. It is about separation of concerns
(at least for now). I have only little experience with database
migrations. I know for a fact, that it can become incredibly complex
if you upgrade releases on a 1/2 year release cycle basis, when
maintaining a database of 15 schemata with 400 tables and 800 views,
100 packages, synonyms, sequences, triggers, UDT's and Oracle AQ's.
I'm glad I have co-workers doing that for me... :-) Having said this,
I prefer focusing on developing jOOQ to be a DML-tool.

> workflow becomes .
>
> define your schema using migrate4j or something similar
> apply it using "ant task" or "maven task"
> And then regular JOOQ workflow..

Sounds good to me. Already today, you can automate jOOQ source code
generation with ant and/or maven.

> Advantages,
> Everything gets source controlled in a repository using pure Java.

The "pure Java" part is a matter of taste. In this particular case,
I'd prefer XML. It seems more flexible at migration time (e.g. no need
to re-compile a fix to the migration script, possibility of
XSL-transforming the migration, etc). But having a single source
control system for both schema and code is wise.

Thanks a lot for this input. If you gather any experience with such
tools, feel free to share a success story!

Cheers
Lukas

Reply via email to