I have recently stumbled upon your very nice-looking tool in search for a Java database source control and migration tool, as this is a frequently requested feature for jOOQ. jOOQ is a database abstraction library built on top of JDBC, that allows for type-safe SQL construction and execution using its fluent API. It features many advanced and vendor-specific SQL concepts, such as UDT’s / UDF’s, recursive queries, nested selects, ref cursors, etc, and a code-generator generating source code from a database schema. Read more on the jOOQ home page:
The supported set of databases is similar to that of Liquibase, so I thought a cooperation might be interesting for all of us…? Liquibase might be useful to jOOQ to maintain its integration test schemata, whereas jOOQ might be useful to Liquibase to navigate database meta data… A commonly supported and documented integration might be a nice success-story for both tools. E.g.
Maintain and increment a DB schema with Liquibase
Run the jOOQ source code generator to make the upgraded schema available to the client application.
I’ve not seen jooq before, how long has it been around?
I think there is integration between the two projects that would make sense. My first thought is that jooq currently only support DML calls whereas most of the SQL generation within liquibase is DDL. There is support for DML within liquibase changes, however, and one optoin would be to build a liqubase extension that would allow users to specify jooq statements and have them executed within liquibase. Running the jooq generator as an “alwaysRun” change would be a good liquibase extension as well.
Not having ween the jooq codebase, is it designed to support ddl statements? Or is it planned on always only supporting DML?
jOOQ has been “public” for about a year. It began with some experimental releases in late 2010 before finally starting to take off as I’m doing more marketing for it in mid-2011:
Currently, there is no DDL support in jOOQ, as I do not have a lot of experience with that. The difficulty (as you know as well as I do) lies in the subtle and/or not-so-subtle differences between various database dialects. I am open to develop such an extension, though. From a design perspective, there’s nothing preventing it. I could give the refactoring operations mentioned in your manual a priority for early experimentation:
There is also nothing wrong with having jOOQ focus purely on DML support, since that is what people need executing within their applications normally. There is definitely some advanatages to your approach over the hibernate/orm pattern. DDL is normally a part of application startup, and there may be a good suggested architecture of liquibase for tracking/managing your database version and jooq for running your application without a lot of overlap or need to duplicate effort between the projects.
At the time, I had had a closer look at how our tools could be better integrated. I had then decided to postpone any large feature increments in jOOQ towards DDL support. This was mainly a matter of priorities, towards more elaborate DML support. That´s why I didn´t follow up on this discussion here.
However, I´d be interested to hear about any concrete integration proposals from a user perspective.
For now, I will attempt to provide adapters for Liquibase types, to use the Liquibase meta model in jOOQ. There are a lot of similarities in the meta-model, between the two APIs:
