“No SQL” with Liquibase and jOOQ

Not NoSQL but accessing a conventional database with “no SQL”. I don’t hate SQL but I do avoid writing it if possible.  Java and SQL don’t go well together. Large volumes of SQL can become a maintenance nightmare if you’re changing your domain model around.

Yes, I know. The model should hardly change as it should have been perfectly architected from the very beginning of the project……..don’t get me started.

I have always used Hibernate/iBatis in conjunction with Liquibase but wanted to try something else. Even the infallible Hibernate can become a little tedious sometimes. My friend Google led me to jOOQ. It’s a fully-featured database framework with all the bells and whistles you can think of. Any database architect will appreciate its SQL-centric approach.

I had a whirl with it’s code generation feature and was impressed. With Liquibase versioning the database and jOOQ reverse engineering it to generate Java objects I felt assured I had a solid, fault-free build (as far as mapping Java objects to database tables goes). One minor niggle is that if you’re using Maven you will find that the jooq-codegen-maven plugin will run at the generate-sources phase whereas the liquibase-maven-plugin normally runs at process-resources. The problem being that we want to manipulate the database before reverse engineering it.

This is easily fixed by changing the liquibase-maven-plugin phase to generate-sources and then adding a concise [cough] bit of Maven to copy the required Liquibase files into the target directory (earlier than it would normally):