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
