jOOQ vs Hibernate

[Robert Liguori]

Hi, we've been doing just basic SQL with JDBC... but our next project is much more complex so we are looking at Hibernate for an ORM solution... but the Hibernate community appears to be dead.

Note that I just stumbled upon jOOQ.  Are there any shortfalls with jOOQ?  Does it rival Hibernate?

If I was going to try to sell this API to my management over Hibernate, what would I tell them?

Thank you so much,
Robert

[Jason Herr]

* jOOQ is less configuration, less overhead and less learning curve.  

* Your get new getters and setters in your beans simply by changing the schema.  

* If you MUST pull composite objects in one query, that's a bit harder in jOOQ.  But in the end, I prefer jOOQ because it doesn't try to do all that and allows me to make my factories return what I want when I want it.

* Schema changes are more reliably reported at compilation times.

* Integration tests are easier to write.

* Quicker turnaround from concept to implementation due to reduced configuration and errors that come from it.

That's what my team saw.

J

--
You received this message because you are subscribed to the Google Groups "jOOQ User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jooq-user+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Witold Szczerba]

Jason's right. I would add that Hibernate and C.O. (JPA) are very easy to start. It's like big WOW!

The thing is they are actually extremely complex frameworks, so the easy beginnings, as your app grows, start to vanish. Then comes the troubles. I mean THE troubles. If you are lucky and your app is really just a simple CRUD - you may miss the party, but it's often not so easy. Of course, eventually you'll find your way through it, but sometimes the time spent on figuring out WTF can be higher than it's all worth.

jOOQ, on the other hand, is a clean and straight representation of SQL within Java, with a little bit of sugar on top, to make your coding-life sweeter. No need to make PHD to get out of troubles you may encounter.

Regards,
Witold Szczerba

[Lukas Eder]

Hi Robert

(and thank you Jason and Witold for your interesting insights)

I hope you don't mind if I elaborate a little. This is an important question, and it deserves careful thinking.

First off, let's bring this discussion to a higher level. Instead of deciding between Hibernate and jOOQ as concrete implementations of their own domains, let's think about ORM vs. SQL, and their different use-cases.

When deciding between an ORM (e.g. Hibernate) and SQL (e.g. jOOQ), the driving question that you should ask yourself is not the question of project complexity. Some of our most demanding customers are using jOOQ on medium-sized schemas with thousands of tables / views. Often, those schemas are extremely normalised and sometimes even deployed on as many as six different RDBMS. jOOQ was specifically designed to work in these scenarios, while keeping the simple use-case in mind as well.

So, instead of thinking about project complexity, ask yourself the following questions:

1. Will your data model drive your application design, or will your application design drive your data model(s)?

A main aspect here is the question whether you "care" about your database in the sense of whether it might survive your application. Very often, applications come and go. They may be re-written in Python / JavaScript, etc. 5 years down the line. Or you have multiple applications accessing the same database: Your Java application, some Perl scripts, stored procedures, etc. If this is the case, database design is a priority in your project, and jOOQ works extremely well in these setups.

If you don't necessarily "care" about your database in the sense that you just want to "persist" your Java domain somewhere, and this happens to be a relational database, then Hibernate might be a better choice - at least in early stages of your project, because you can easily generate your database schema from your Entity model.

2. Will you do mostly complex reading and simple writing, or will you engage in complex writing?

SQL really shines when reading is complex. When you join many tables, when you aggregate data in your database, when you do reporting, when you do bulk reading and writing. You think of your data in terms of set theory, e.g. your data as a whole. Writing CRUD with SQL is boring, though. This is why jOOQ also provides you with an ActiveRecord-style API that handles the boring parts, when you're operating on single tables (Jason mentioned this).

If, however, your writing becomes complex, i.e. you have to load a complex object graph with 20 entities involved into memory, perform optimistic locking on it, modify it in many different ways and then persist it again in one go, then SQL / jOOQ will not help you. This is what Hibernate has originally been created for.

My personal opinion

I believe that data is forever. You should *always* assume that your database survives your application. It is much easier to rewrite (parts of) an application than to migrate a database. Having a clean and well-designed database schema will always pay off down the line of a project, specifically of a complex project.

Also, most projects really do 90% reading and 10% writing, writing often not being complex (2-3 tables modified within a transaction). This means that most of the time, the complexity solved by Hibernate / JPA's first and second level caches is not needed. People often misunderstand these features and simply turn off caching, flushing Hibernate's cache to the server all the time, and thus using Hibernate in the wrong way.

If, however, you're undecided about the above two axes of decision, you can go the middle way and use jOOQ only for reporting, batch processing, etc. and use Hibernate for your CRUD - in a CQRS (Command Query Responsibility Segregation: http://martinfowler.com/bliki/CQRS.html) style. There are also quite a few jOOQ users who have chosen this path.

Last but not least, here are some additional resources:

http://www.hibernate-alternative.com (summarises this e-mail)

http://www.jooq.org/why-jOOQ.pdf (for your management)

but the Hibernate community appears to be dead.

May I ask you what made you think this way?

Best Regards,
Lukas

--

[Stéphane Cl]

I have used both jooq and hibernate with many projects. Both tools are very capable.

Other than that, a quick summary :

Hibernate :
1) Requires more learning. As Witold said, your first project with this framework can easily turn into a nightmare. You may step into every single trap if you don't have a good understanding of how it works under the hood.
2) Hibernate is good at loading large graphs of objects, eg: collections of customers + their individual collection of orders (+ orderdetails, +products + ATV info). Such things require more job with jooq.
3) I would not use Hibernate on an existing database which I don't have full DDL control on.
4) Never trust people saying that using hibernate saves you from knowing SQL
5) Stick to simple mappings, don't try to achieve pure OO.
6) If most of your project consists in loading tabular data sets (eg: aggregates, reporting) skip hibernate


Jooq :
1) If you are fluent with SQL, there isn't much to learn, you'll feel right at home
2) Excellent for writing even the most complex queries, correlated queries, anti-joins, aggregates, invoking stored procedures, on hibernate you'd have to revert to raw JDBC for most of these things
3) Jooq doesn't introduce any constraint in the way you design your database, excellent if you need to use an existing DB.
4) Jooq (to my knowledge) doesn't do caching, on the other hand, many people find hibernate session cache misleading. To each his own.

Both solutions aren't mutually exclusive, I have written an hybrid app using hibernate for business logic and Jooq for reporting/statistics/aggregates and I am very satisfied of the result. It is easy to obtain a JDBC connection from hibernate because their authors knew that user would have no choice but to use raw SQL in some situations. Jooq factories only require a JDBC connection, they are cheap to create, so there is no reason not to use them for all your non-ORM needs.