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):