Thank you for your talk! As usual, it convinced me get rid of JPA/Hibernate again and again. After every talk about JPA, I hate my laziness because of not switching to another, I realize I only use JPA for 'create' because I'm lazy at making a insert statement at the beginning, for others like 'update', 'delete', and especially 'read', I always have to use specific @Query instead to bypass JPA drawbacks.
Why are you even using an ORM when you are not using it as an ORM?! Serious skill issues here. I love Spring JPA, and I build custom query languages with it with the stroke of a brush. But you do have to be aware of how data bases work, how to build good schemas and how to query efficiently. Besides obviously learning how JPA/Hibernate works under the hood.
That part about the interface projections is very very interesting. Great session and really worth watching if one is used to working with the JPA. Especially when finding limitations to what we are doing.
you can't replace List to Set on most cases, if u are going to persist on cascade that collection too AND the IDs (used by equals to determinate uniqueness) of those elements are still null. Like items.add(new OrderItem(null, product, quantity, price)), when you try to add the second will fail
Thorben must wear his white t-shirt + sky blue shirt whenever he talks about Hibernate. Excellent content as always, by the way. I have learnt so much with him over the years 💪
My recommendation would be to not use JPA at all, the fact that you need to know all that stuff to not hurt yourself due to incorrect framework usage (not even talking about DB performance issues) looks like a bad thing to begin with. Simpler tools like jooq seem to be better ?
@@hardcorecode If we are being honest, in pretty much any production system you will never let Hibernate generate the database for you and instead use Flyway or Liquibase to generate the database. So I don't think that's a bad thing.
All those recommendations are clear to everyone who has two years of programming experience
weird flex
Thank you for your talk! As usual, it convinced me get rid of JPA/Hibernate again and again. After every talk about JPA, I hate my laziness because of not switching to another, I realize I only use JPA for 'create' because I'm lazy at making a insert statement at the beginning, for others like 'update', 'delete', and especially 'read', I always have to use specific @Query instead to bypass JPA drawbacks.
JPA is good for giving demos with CRUD operations, it will suck in production.
Then what you suggest to use instead of JPA? @@praveens2272
Why are you even using an ORM when you are not using it as an ORM?! Serious skill issues here.
I love Spring JPA, and I build custom query languages with it with the stroke of a brush. But you do have to be aware of how data bases work, how to build good schemas and how to query efficiently. Besides obviously learning how JPA/Hibernate works under the hood.
That hibernate session metrics are very useful.
This talk is very good.
That part about the interface projections is very very interesting. Great session and really worth watching if one is used to working with the JPA. Especially when finding limitations to what we are doing.
31:38 In what cases do you use interface in projections?
What are the advantages over dto, record?
There is no advantage, same thing. Use whatever you feel like
Hi @Thorben, Thanks for the session. It was quite insightful.
you can't replace List to Set on most cases, if u are going to persist on cascade that collection too AND the IDs (used by equals to determinate uniqueness) of those elements are still null. Like items.add(new OrderItem(null, product, quantity, price)), when you try to add the second will fail
Thorben must wear his white t-shirt + sky blue shirt whenever he talks about Hibernate.
Excellent content as always, by the way. I have learnt so much with him over the years 💪
Frankly I will use jpa as simple selects for smaller projects elsewhere pure jdbc does the job or plsql
My recommendation would be to not use JPA at all, the fact that you need to know all that stuff to not hurt yourself due to incorrect framework usage (not even talking about DB performance issues) looks like a bad thing to begin with. Simpler tools like jooq seem to be better ?
jooq is not code first. it requires a database schema to already exist! that's why it's simpler! JOOQ and JPA are two completely diferent things!
@@hardcorecode If we are being honest, in pretty much any production system you will never let Hibernate generate the database for you and instead use Flyway or Liquibase to generate the database. So I don't think that's a bad thing.
@@rodjenihm true! what about developement! Nobody is going to let you touch there production database!! So how would you use JOOQ then?
Why not use Golang then? That's even more abstract layers off
@@hardcorecode try jooq for yourself
Nice, thanks.
Write high speed code, then you won't need caching. Wrting code that deals with caching slows down your program. Caching always causes problems.
Give me one reason ( besides query+ db ) to use jpa. Im just asking
Optimistic locking
Pessimistic locking, versioning field/attribute, boosting start up on every project
That remove example was bonkers! using lists should not have that much of a performance penalty!