Do you really need Hibernate by Simon Martinelli @ Spring I/O 2023

Spring I/O 2023 - Barcelona, 18-19 May
Slides: speakerdeck.co...
GitHub repo: github.com/sim...
Hibernate is often used without thinking twice. But is that the best solution in all cases? This talk shows another possibility that can lead to better performance in many cases.
Projects often use Java Persistence API (JPA) by default and, thus, mostly Hibernate. But do all applications need a comprehensive object/relational mapping (ORM) with all conceivable functions?
This talk examines the architecture of database-centric applications and discusses whether you always need an object graph for persistence.
Using an example application, it is shown how pure SQL, with the help of jOOQ and (nested) Java Records simplifies data access and how common ORM problems, such as the n+1 select problem, can be avoided. Finally, the possibility of combining jOOQ and JPA/Hibernate and thus using the best of both worlds is discussed.

[@d47im5e]

Thanks for the great session.

[@jamilxt]

Thank you!😁

[@SleePokeR]

JOOQ looks really nice. I hope I'll have a chance to try it at work :)

[@praveens2272]

Was waiting for this

[@MrMikopi]

Do any of you suggest implementing JOOQ to a project with Hibernate already implemented? Or is it more like a migration from Hibernate to JOOQ?

[@macctosh]

Idk, I for one prefer hibernate’s, magic strings(@query). I just can’t imagine a SQL query taking up a whole page/file. In my application I have to write hundreds of long sql queries. I do agree that they may be hard to maintain, but when I write magic strings in a reasonably sized repository, I find it pretty easy to maintain.

[@1dayitwillmake763]

I think this was a great talk, but I think the framing of it as a battle between J00Q and JPA did not do him any favors. I think people would have been more receptive if he would have framed it as “Hey did you know JOOQ could do X?”, people could then draw their own conclusions

[@simonmartinelli]

What battle are you referring to? The talk explains how jOOQ works and in which scenarios it may be a better fit. Please tell me your thoughts so I can improve my talk. Thanks

[@1dayitwillmake763]

@@simonmartinelli First, as I mentioned I really enjoyed this talk. You highlighted some great usages of JOOQ, which is a cool technology. However, the "tone" of the talk, came off as being a shot at JPA. Some of it is not your fault though, it's just a sensitive topic to some (for some reason 🤣)

[@alexandr7686]

It is better only on the paper and for small or pet projects. When you have large project you will have to spend too much time for maintaining and writing tests not to miss something on the repository layer, because after couple of years you will not be sure that when you add something in one place other won't be broken, same as in mybatis. JPA\Hibernate is more predictable and well stande for long distance. If you need something tricky just use native queries, that's all. Really don't recommend JOOQ, MyBatis or something similar if you are not just playing with pet project.

[@praveens2272]

Maintaining JPA entities relationships are very hard and you don't know if you fetch one entity and it will also fetch dependent entities which we don't want. SQL like syntax will always be good. Love JOOQ.

[@alexandr7686]

@@praveens2272 It is not hard if you use tool correct, all possible cases are 100 times discussed and all solutions\workarounds provided. But when using tools like JOOQ you'l never know what will fail\broke in runtime on production in next release.

[@ilyaivanov3365]

@@alexandr7686 Can you elaborate more on 'you'l never know what will fail\broke in runtime on production in next release'? What makes you think so?

[@alexandr7686]

@@ilyaivanov3365 as an example you have lots of entities and join queries between them, and map result to different DTO's, after some time you add new field, and can easily miss new field at some place, because you forgot to add this new field to some query. This mistake will be found only during runtime. Due to that you have to write 10500 tests for CRUD operations, and I would say for everything in data layer. At the end you will be writing more tests other then useful code. Same for field deletion, and especially for any deletion, you can get constraint violation for child, dependendent entities only at runtime. JPA\Hibernate manages this more easy, etc. I'm not saying it is impossible to leave(manage) with that, but main point is not to make persistent layer pain in the ass.

[@ilyaivanov3365]

​@@alexandr7686 About addition of new field - you should be fine. Mapping to DTOs does not blow up if query result has more fields than your DTO. So if your code worked fine without that new field it will continue to work. About the deletion of a field. If it was in use it will break things certainly. But jooq should be used with generated schema classes, you have to regenerate them whenever you do a db schema change. This will update your pojos removing the field and you get compilation error where you have referenced it. If it was never referenced - you are good, no code changes needed. How would JPA/Hibernate handle the field deletion?

[@carnaedy]

That... is a lot of effort for something you could do in a few dozen lines with Spring Data JDBC / Spring Data R2DBC. Even if you consider JPA to be evil, which is fair enough, reverting to slightly glorified SQL is a vast overkill. CRUD is not interesting. Explicitly writing Java code for CRUD is wasted effort, and that code is incredibly fragile. I have used JOOQ in production, and I would never do it again.

[@chauchau0825]

Do you really need JOOQ? Thanks but no thanks.

[@921xmecha]

Maven ... lost me there.

[@gsilva877]

You dismiss the entire talk because he do not use your favorite build tool? That has not logic and is neither a constructive critique.

[@921xmecha]

Got burned once to many. And just to be clear. Conceptually I prefer the model of Maven over gradle. But the latter actually does compile avoidance. And understands dependencies. Maybe the maven has improved since the last time I used it, maybe not. Will leave it to someone else to play with it.

[@vidzeditz8537]

You can use jooq easily with gradle