Great talk and thanks for the shout out!

This is an absolute goldmine, thanks Maciej!!! We have a part of our application that takes about 40ms to do a simple insert so this talk is excellently timed 👌🏻

Awesome talk, Maciej. One can not emphasis enough the importance of understanding what's going on behind Hibernate & Spring Data JPA - I really liked the wallpaper 🍃

Thanks for sharing. More sessions like this please!

Pure gold! Thank you so much for the awesome presentation.

Very very good talk, hands on and i took away at least 4 things that i did not know or did not fully understand before. Thanks!

Good talk, thank you Maciej

Definitely need to try PROJECTIONS ...

If anyone doesn't understand jpa and hibernate at this level(internal workings), they will screw up the application. I think it's better to write plain SQL queries and execute or may be JOOQ helpful.

This was exceptionally useful, thanks mr. Walkowiak

This was exceptional. Thanks

Very very good talk. I enjoyed it

thank you for this amazing talk

it was really helpful. thank you for your hard work

Nice video!

I once attended one of Vlad's lectures at the JAX and i had the feeling (same as here) that the time is over, when it is getting interesting.

Vlad actually used to work on the Hibernate project for RedHat in the past at some point.

34:34 "It's a commercial tool, which is great.. for Vlad" ROTFL!! 🤣🤣🤣

I have a question in bank transfer execute method he said hibernate will open the session then closes in case of findById.But earlier he said because of OSIV it mantains a session throughout request after a db call. can anyone answer

Is there any reason you did not fix the aggregate model instead? It's a phenomenon I run into quite frequently: folks run into performance problems and immediately resort to tweaking persistence metadata, when *actually* the problem is in the model itself. Spring Data deals with DDD aggregates, in which Many-to-One relationships to other aggregates have no place at all. Those would be modeled as identifier references instead, so that these are basic values to Hibernate, and it would not need to resolve references The entire lazy/eager discussion is avoided on the Hibernate level. No get-by-reference tricks, no tweaking of Hibernate metadata. Applications would simply resolve the identifiers when they *actually* need the reference. Creating a BankTransfer wouldn't even need to resolve the accounts beforehand.

First YAGNI Spring

Simple answer is dont use Hibernate, It makes simple problem more simpler (which we might not need) and complex problem more complex (which we definatly not need it), Got for micro framework like MyBatis if you really want to consider performance, its great sweet point.

27:20 I didn't understand how annotating the execute() method with @Transactional reduced the number of database queries. Can someone explain pls?

Using hibernate for 5 years, I agree that it is not the best tool for database handling. Most of the time plain SQL is much more predictable and easy to work with

cant even lazy load one to one

This demo code is available in GitHub? If not please share the link. Thanks.

Or use SQL and clojure with it's awesome data strucutres :)

Do you have a long running transaction? just split it into two transactions 😂

Projections with nested entities are sucks ...