Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Problems with JPA/Hibernate

stemlaur.com

Post reply on HN
Print view View original

141–150 of 195 posts

Re: Problems with JPA/Hibernate

#141

Post by ChrisWreck »

oweiler wrote: post #114
kleinsch wrote: post #55

Everyone hates JPA/Hibernate, but what’s the alternative? I’ve seen this a few times. “You don’t need an ORM, write your own SQL queries directly and create a beautiful domain driven design object model” leads straight into a project only the owner will understand. Homegrown mini-ORM that’s full of pitfalls, inconsistent object model, hacks and TODOs all over the place. If you’re living in the Java ecosystem, the big…

Both JOOQ and JDBI are superior to JPA in my book.

jOOQ and JPA doesn't solve the same problem.

Re: Problems with JPA/Hibernate

#143

Post by ChrisWreck »

manyxcxi wrote: post #85
lmm wrote: post #80

This is a common criticism but still extremely shallow. JPA/Hibernate is still the best way to actually produce working applications if you have to use an SQL database for some reason. To go point by point: Mutable datastructures with default constructors and setters: yes, mutable entities suck. Unfortunately SQL is fundamentally built around mutable entities. Every field of your POJO is writable because every column…

I disagree on most of your points but I am trying to read your entire comment favorably, but my personal experiences do not line up with almost any of this. >>> JPA/Hibernate is still the best way to actually produce working applications if you have to use an SQL database for some reason... This statement makes me think that you either do not prefer to use SQL RDBMS, don’t have to use them very often, believe they ar…

> I expect every single one of my backend engineers (on any tech stack) to understand the fundamentals of SQL INSERT, UPDATE, and DELETE statements.

Understanding INSERT, UPDATE, and DELETE doesn't help you very much when you have to persist changes to a single child entity of many in an aggregate (parent entity). How do you track which child has changed? Or if a new child is added? Or one is deleted? Or what if the relation is a child of a child of the aggregate, which might very well be the best way to model your domain.

In these situations, Hibernate/JPA will help you a lot! If you're doing it using plain SQL/JDBC, you'll probably end up writing your own mini ORM, and/or polluting your domain with database concerns. (I do keep my Hibernate entities separated from my domain.)

Re: Problems with JPA/Hibernate

#144

Post by Quarrelsome »

kleinsch wrote: post #55

Everyone hates JPA/Hibernate, but what’s the alternative? I’ve seen this a few times. “You don’t need an ORM, write your own SQL queries directly and create a beautiful domain driven design object model” leads straight into a project only the owner will understand. Homegrown mini-ORM that’s full of pitfalls, inconsistent object model, hacks and TODOs all over the place. If you’re living in the Java ecosystem, the big…

C# have micro-ORMs like Dapper, surely Java has smth similar? Micro-ORMs show the SQL but the object generation still gets done for you so you get a bit of both worlds.

Re: Problems with JPA/Hibernate

#145

Post by ChrisWreck »

amenghra wrote: post #99

I solve Hibernate problems by using jOOQ instead. The migration more than paid off the couple times I did it.

How do you solve storing/updating/removing child entities of another entity (which also may be a child of another entity) effectively?

I use jOOQ as well, but mostly only for the reading part. For the above case, I still use Hibernate, as I've yet to find an efficient way to do it in jOOQ.

Re: Problems with JPA/Hibernate

#146

Post by eeperson »

watwut wrote: post #121
eeperson wrote: post #61

Earlier quoted context omitted.

I'm not talking about "dirty checking". I'm talking about "automatic dirty checking". Take for example this code I got from this article[1]: SessionFactory sessionFactory = HibernateUtil.getSessionFactory(); Session session = sessionFactory.openSession(); Transaction tx = session.beginTransaction(); Person person = session.load(Person.class, 2); //loads Person object for id 2 person.setAge(32); tx.commit(); session.c…

That is because "session.load(Person.class, 2)" line literally says "and track changes" - as article says. That is not how Hibernate or JPA is used normally. It is going out of standard way to achieve the thing you complain about.

> That is because "session.load(Person.class, 2)" line literally says "and track changes" - as article says.

I'm aware that that what occurs. That is my point. I'm responding to the previous posts statement "No calling a setter on an Entity doesn't automatically issue an sql UPDATE query". This is an example where calling a setter causes an update query to be run.

> That is not how Hibernate or JPA is used normally. It is going out of standard way to achieve the thing you complain about.

What about this not not how Hibernate and JPA are used normally? Are you saying that setters are not normally used? Do you mean that people normally call update or merge to persist an Entity? If so, I agree that is what people normally do. However, when people do that they tend to accidentally introduce bugs. Usually this occurs when they update an entity and then do some validation on it. When the validation fails they think they can avoid sending he changes to the DB by doing nothing. However, that isn't true. They have to manually evict the entity from the session to prevent that from happening.

Re: Problems with JPA/Hibernate

#147

Post by krzyk »

lmm wrote: post #80

This is a common criticism but still extremely shallow. JPA/Hibernate is still the best way to actually produce working applications if you have to use an SQL database for some reason. To go point by point: Mutable datastructures with default constructors and setters: yes, mutable entities suck. Unfortunately SQL is fundamentally built around mutable entities. Every field of your POJO is writable because every column…

> Do you really think people who can't be bothered to learn and understand Hibernate properly are somehow going to take the time to learn and understand "vanilla SQL"? Why?

Because JPA is a magnitude larger space to learn than just SQL.

Or more precisely: using Hibernate in simple applications (CRUD) will cause you issues very soon (sessions missing), some magical saving of data when you a set, doing filtering in streams (and now you take too much fields).

Doing the same with SQL (using JDBC or something like JDBI) won't cause that for simple apps.

Re: Problems with JPA/Hibernate

#148

Post by ChrisWreck »

Going from using only JPA/Hibernate for everything, to use a combination of both jOOQ and JPA/Hibernate on a project, is probably the best decision I've made. Using each tool at what I believe they do best.

I use JPA/Hibernate for most writing and inserts. It helps a lot when you're dealing with aggregates with child and child entities. It would be a nightmare to track all changes myself and try do manually do what the ORM is doing for me. Deleted a child of a child of an aggregate? No problem, persist only that.

I've started to separate my JPA/Hibernate entities from my domain models as well, and it looks promising. There's some more mappins, but my domain won't be polluted with database concerns.

Then I use jOOQ for almost all reading of data, reading into custom read models that fit the view they are supposed to be shown in. No problem doing multiple joins or other stuff that would give you an immediate headache when trying to solve using JPA/Hibernate.

Re: Problems with JPA/Hibernate

#149

Post by eeperson »

vips7L wrote: post #63
eeperson wrote: post #61

Earlier quoted context omitted.

I'm not talking about "dirty checking". I'm talking about "automatic dirty checking". Take for example this code I got from this article[1]: SessionFactory sessionFactory = HibernateUtil.getSessionFactory(); Session session = sessionFactory.openSession(); Transaction tx = session.beginTransaction(); Person person = session.load(Person.class, 2); //loads Person object for id 2 person.setAge(32); tx.commit(); session.c…

That's because JPA isn't involved here. It's directly using hibernate api's and not sticking to the standard which is what I was talking about.

Have you verified that? I'm pretty sure that occurs using the JPA API and Hibernate. I'm not sure if other JPA providers do this as well.

Re: Problems with JPA/Hibernate

#150

Post by ChrisWreck »

lazystone wrote: post #142
ChrisWreck wrote: post #141

Earlier quoted context omitted.

jOOQ and JPA doesn't solve the same problem.

That's why JOOQ is superior.

It depends on what you want to do.

Complex queries with multiple joins? jOOQ.

Persist changes to complex aggregate models with multiple layers of child entities? JPA/Hibernate.

Post reply on HN