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

121–130 of 195 posts

Re: Problems with JPA/Hibernate

#121

Post by watwut »

eeperson wrote: post #61
vips7L wrote: post #53

Earlier quoted context omitted.

No calling a setter on an Entity doesn't automatically issue an sql UPDATE query. You need to ask the EntityManager to merge or persist the entity and it's changes. Obviously JPA knows what fields were updated via dirty checking.. that's almost half the point of an ORM.

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.

Re: Problems with JPA/Hibernate

#122

Post by watwut »

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…

I dont think it is true that everyone hates JPA/Hibernate. I dont hate them and dont know many people IRL who hate them. I know SQL, worked with SQL before Hibernate. Here, developers are expected to learn SQL even as project is using Hibernate.

For me, migration to Hibernate was improvement. There is a subculture of people who hate Hibernate, hate Java, hate frameworks for anything. And some of these people are very vocal and emotional about it. And then there is everybody else.

And a lot of it honestly sounds like projection. People who dont like to have to learn these things and quite clearly did not bothered to learn them. They assume Hibernate is used to avoid learning SQL, because that would make sense to them. But, back in real java world, developers are expected to know both.

Re: Problems with JPA/Hibernate

#123

Post by watwut »

kgeist wrote: post #105

Interesting, as far as I know, PHP's Doctrine was influenced by Hibernate but it doesn't require parameterless constructors, and data is hydrated directly as object fields, without requiring getters/setters. What's the reason for enforcing such requirements in Hibernate?

It is JPA requirement. In java, if you are creating new object, you have to call some constructor. If you dont have no parameter constructor, the framework would have to somehow call a constructor with right paramaters. The date are filled directly to fields. But no parameter constructor is needed so that object can be created in the first place.

Now, in Hibernate itself, the no-parameter constructor is not needed. Hibernate supports an "interception mechanism" which allows you to use whatever constructor you like. But that is not part of JPA standards and for most it is simpler to just go standard way.

Re: Problems with JPA/Hibernate

#124

Post by eitland »

sabellito wrote: post #111
eitland wrote: post #108

Earlier quoted context omitted.

Generally you should use the right tool for the job and that might be something else. This however: > You get to throw away all the semantics built into the database structure, including knowledge about indexes, suggests you either don't know JPA very well or your writing is a bit sloppy. Please avoid making sweeping generalisations about tools that save hundreds (or al lot more) of hours of programmer tools just bec…

They made some concrete criticism based on their experience (hard to maintain, complex annotations, etc), but you in turn dismissed those with "you didn't get" and some borderline name-calling. Which bit they didn't get?

doctor_eval wrote:

>> You get to throw away all the semantics built into the database structure, including knowledge about indexes,

I wrote:

> suggests you either don't know JPA very well or your writing is a bit sloppy.

To suggest that JPA means "throw[ing] away all the semantics built into the database structure, including knowledge about indexes" indicates either that the person doesn't know what JPA is about: indexes should be used with JPA for all but the most trivial setups. Same goes for other general database knowledge.

You wrote:

> They made some concrete criticism based on their experience (hard to maintain, complex annotations, etc),

I just pointed out that it was either a misunderstanding or so sloppily written as to create misunderstandings.

> but you in turn dismissed those with "you didn't get" and some borderline name-calling. Which bit they didn't get?

The bit about JPA not standing in the way of using good database practices.

It is not name-calling. I point to the exact words doctor_eval uses. To be polite and also be sure to make room for error on my side I also offer the option of sloppy writing. Sloppy writing happens to all of us and I'll be happy to know if doctor_eval didn't mean it or if I've misread it.

If not however it is not smart to use big words to try to trash a super useful tool that save many of us lots of time and often increase quality.

Re: Problems with JPA/Hibernate

#125

Post by watwut »

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 fully agree.

> 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?

Yep, that is exactly what I think. People who know Hibernate know also SQL. People dont bother learn, dont know either. And then there are people who know only SQL, because they worked on projects without Hibernate. They typically learn Hibernate fast.

Re: Problems with JPA/Hibernate

#126

Post by jillesvangurp »

dale_glass wrote: post #25

I disagree with this bit: A User can be considered unique in one context by its email address, or by its social security number Personally, I'm a fan of giving everything a random UUID, because it's more flexible. It's random and impossible to guess, it scales well because there's no central bottleneck like with an autoincrement, and it's future proof and flexible. What happens when the user changes the email address…

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 the user is one step up over this. Not lot of websites actually do this. Linkedin is one of them; because they recognized early that they needed to track their users as they changed their professional affiliation.

I tend to use list fields for things like phone numbers and email addresses. This makes it clear that I understand that users might legitimately have several of those and that they change over time. I always liked what Keybase did with encouraging its users to have multiple verified third party identities (the more the better).

Using a social security number is a mistake for a different reason: it's a sensitive bit of information that can be abused if it falls in the wrong hands. You should protect it like you would protect a credit card number and generally not store it unless you absolutely have a valid business reason to. Also, it's country specific which sort of makes it an obstacle if you need to serve an international market (or have the ambition to do so later).

Re: Problems with JPA/Hibernate

#127

Post by watwut »

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.

And everyone knows them. It is just absurd to talk about Hibernate as a way to avoid learning to write insert, update and delete. That is made up issue. That is like claiming that people who dont write getters and setters dislike them because they did not learned how to write them.

I dont know whether this claim is a manipulative attempt to try to insult people who like framework you dont or what. But it is ridiculous.

Re: Problems with JPA/Hibernate

#128

Post by dirkt »

Uehreka wrote: post #92

Sorry for being off-topic, but why is Hibernate called Hibernate? I can't find an explanation on the Wikipedia or GitHub pages, and whenever I see the name come up on HN my brain does a weird double-take as it goes "Is this an OS hibernation tool--No, it's the Java database thing... does it make objects go to sleep?"

Yes, it makes your objects go to sleep.

The use case is "you have a collection of objects that reference each other in memory. You want to say: Bam, put that structure like it is into a database ("put it to sleep"), and retrieve it again for me if I need it ("wake it up after winter is gone")."

For this type of ORM Hibernate works fine. If you want to use a database as a database, it resists at every turn.

Re: Problems with JPA/Hibernate

#129

Post by watwut »

> Nobody understands the cache mechanism, you end up de-activating it. Worse, those understanding it are not caching query responses, they are caching entities.

I feel like hiring process should filter these kind of developers out. At least most of them.

I also think that if they get in, internal processes should limit these developers impact, limit their ability to make decisions. As in their careers should be stagnant and they should not be gaining influence.

Re: Problems with JPA/Hibernate

#130

Post by debarshri »

doctor_eval wrote: post #52

In my extensive experience managing teams using JPA ORMs including Hibernate and EclipseLink, you not only get to learn the unavoidable details of your target database’s SQL, but also the complex, non-obvious side effects - especially caching interactions and performance edge cases - of the ORM as well. You also get to learn two distinct but similar query languages (one of which you can’t use anywhere else but Java).…

Have you ever tried - ormlite-core[1]?

I recently found this obscure but quite stable library, kind of fell in love with it.

[1] https://github.com/j256/ormlite-core

Post reply on HN