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

171–180 of 195 posts

Re: Problems with JPA/Hibernate

#171

Post by jacques_chester »

haspok wrote: post #137
jacques_chester wrote: post #31

Earlier quoted context omitted.

> What if the social security number changes, because it was wrong or because it actually changes? What if the user doesn't have an SSN? What happens if they have one but lawfully refuse to provide it? What happens when you ask for and SSN from a US citizen who is also a European citizen? What happens when your database leaks? In general, relying only on natural keys is a nightmare. Double nightmare if it's PII. Natu…

How do you look for a person, if not based on his/her SSN? SSN alone is not sufficient, of course. But it _is_ definitely part of the natural key that you use _implicitly_ ANYWAY, whether recognizing it or not. > Natural keys only work if you are flawlessly omniscient about the domain I would call that BS. Nobody is "flawlessly omniscient" about anything, not even in mathematics, yet we design and build systems that…

> I would call that BS. Nobody is "flawlessly omniscient" about anything, not even in mathematics, yet we design and build systems that work.

And such systems typically use synthetic keys to completely dodge the kind of problems I outlined.

The problems with natural keys are that you, the programmer, don't know as much as you think you know. You muddle the problem domain with the solution domain and when something comes along in the problem domain you didn't think of, it's now much harder to fix.

> On the other hand, yes, it is a very good requirement to have someone on the team during database modeling who understands the domain model thoroughly. No UUID columns will save you from that.

They save you from having to work out how to store a record when you chose SSN as primary key and discover that, uh, no you can't do that. The same goes for purchase order numbers, waybill numbers, student IDs, payroll IDs, bank account numbers, license plates ... anything whatsoever that is visible in the problem domain will or will have exceptions you didn't know about, didn't foresee and for which legislation or policy allows no exception for not using a UUID column.

Re: Problems with JPA/Hibernate

#172

Post by jillesvangurp »

imtringued wrote: post #165
jillesvangurp wrote: post #126

Earlier quoted context omitted.

It's a common mistake indeed. People change company, which means their email will change. Or they are affiliated with multiple companies. Or they simply sign up with their personal email. If you have more user objects than people in your system, you are doing something wrong. This kind of digital schizophrenia is unfortunately quite common (looking at you Slack). Having a notion of multiple verified ways to contact t…

>Or they simply sign up with their personal email. If you have more user objects than people in your system, you are doing something wrong. I have three discord accounts and there is no way to avoid that.

Github manages fine. I've used my account on numerous projects. Github simply recognizes that you are you and that your account and your company's data are two things.

Re: Problems with JPA/Hibernate

#173

Post by alserio »

watwut wrote: post #162
eeperson wrote: post #146

Earlier quoted context omitted.

> 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.…

The "session.load(Person.class, 2)" thing is not done normally. It is not even part of JPA. It is hibernate only feature. So in all project I have seen, calling setter did not changed database. > Do you mean that people normally call update or merge to persist an Entity? Yes, people normally call update and merge to persist an entity.

People normally do that when they do not have to do that.

  Dog rex = em.find(Dog.class,"rex"); // 1
  rex.setAge(2); // 2
  // other query // 3
At 3 the update is flushed on the underlying db. This is pure JPA. Calling merge is forcing an useless query before the update. Also, merge returns the managed entity.

Re: Problems with JPA/Hibernate

#174

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.

I'm almost certain this occurs with Hibernate as the JPA provider. I haven't tried this with other JPA providers but as far as I can tell from tutorials[1], stack overflow posts[2], and the JPA documentation[3], this is the default for JPA as well.

[1] - https://www.objectdb.com/java/jpa/persistence/update

[2] - https://stackoverflow.com/a/8307991

[3] - https://docs.oracle.com/javaee/6/tutorial/doc/bnbqw.html#bnb...

EDIT: Oops I accidentally replied to this twice

Re: Problems with JPA/Hibernate

#175

Post by eeperson »

alserio wrote: post #78
eeperson wrote: post #58

Earlier quoted context omitted.

> There are attempts to fix this with e.g. Graal, which effectively does the expensive initialization and reflection at compile time, but there are so many downsides and pitfalls right now with Graal that I don't consider it a serious solution to the problem. It's basically creating a new ecosystem, which means one primary motivation--to take advantage of the Java ecosystem--is much less compelling. I'm not sure I un…

Not gp but avoiding the reflection pitfalls is not so straightforward at all, you have to chase what your dependencies are doing to satisfy the "closed world" hypothesis. I still like java more than javascript, but writing performant serverless functions using js is way more easy right now

You don't have to chase your dependencies. You just need an adequate suite of tests and then run them with the Graal Tracing Agent enabled [1].

[1] - https://medium.com/graalvm/introducing-the-tracing-agent-sim...

Re: Problems with JPA/Hibernate

#176

Post by alserio »

victor106 wrote: post #89

Lot of Hibernate hate in this thread. This really helped me. Strongly suggest. Also Vlad writes really awesome posts on using Hibernate along with Spring etc., https://vladmihalcea.com/courses/

Vlad Mihalcea is awesome! However, Hibernate, while helping in some use cases, in my opinion should not be the default solution one reaches for. It makes way too easy to do things in a way that works for a while and explodes later. And it is way too easy to be misunderstood, leading to performance and compositionality horrors. Still it is the only Java solution I know that manages to be reasonably portable between different DBMS.

Re: Problems with JPA/Hibernate

#177

Post by [deleted] »

eitland wrote: post #109
agilob wrote: post #41

Earlier quoted context omitted.

JPA and Hibernate make it very easy to use it incorrectly, its almost like they promote bad SQL queries and ideas. They let users of database connection to write Java-first database queries, when database query should be database first, it's just way too easy to abuse it and get too much data, too many columns and JOINs. Developers look like JSON looks like, what we send to browser, what formatting it has, validation…

> Hibernate is popular because we don't need to learn SQL to get needed data, but it's also super hard to get it right and don't do something stupid by accident. I think this is plain wrong, or I might have been very lucky with who I work with: if anything I think most people I work with learned JPA or other ORMs long after learning SQL.

[deleted]

Re: Problems with JPA/Hibernate

#178

Post by morelisp »

eitland wrote: post #109
agilob wrote: post #41

Earlier quoted context omitted.

JPA and Hibernate make it very easy to use it incorrectly, its almost like they promote bad SQL queries and ideas. They let users of database connection to write Java-first database queries, when database query should be database first, it's just way too easy to abuse it and get too much data, too many columns and JOINs. Developers look like JSON looks like, what we send to browser, what formatting it has, validation…

> Hibernate is popular because we don't need to learn SQL to get needed data, but it's also super hard to get it right and don't do something stupid by accident. I think this is plain wrong, or I might have been very lucky with who I work with: if anything I think most people I work with learned JPA or other ORMs long after learning SQL.

You have been lucky. Part of our hiring test (intentionally) does something which is trivial to get correct if you know SQL but also easy to get racey with Hibernate. About 4/5 of applicants get it wrong and maybe 2/5 don't know how to fix it when we show them they problem. (Spring devs with 1-5 years experience in web APIs and reporting.)

Re: Problems with JPA/Hibernate

#179

Post by cle »

eeperson wrote: post #175
alserio wrote: post #78

Earlier quoted context omitted.

Not gp but avoiding the reflection pitfalls is not so straightforward at all, you have to chase what your dependencies are doing to satisfy the "closed world" hypothesis. I still like java more than javascript, but writing performant serverless functions using js is way more easy right now

You don't have to chase your dependencies. You just need an adequate suite of tests and then run them with the Graal Tracing Agent enabled [1]. [1] - https://medium.com/graalvm/introducing-the-tracing-agent-sim...

Your tests would need to exercise all your transitive dependencies' code paths that are used in production. I very rarely see tests written that way.

Re: Problems with JPA/Hibernate

#180

Post by Daishiman »

tarkin2 wrote: post #35
Daishiman wrote: post #15

Earlier quoted context omitted.

"Really complex" means getting down to 6 or 7 joins for your typical SQLAlchemy or Django ORM query. These sorts of queries comprise 5% of my queries, tops. Seems like a fair tradeoff.

I have one of those queries. It's the most important in the database sadly. As django bloats and bloats the table space, over the years, more and more do I need those queries, and slower and slower becomes my app.

The mapping of Django models to tables is trivial. Django's not introducing a difficulty, though the entity modeling may be.
Post reply on HN