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

161–170 of 195 posts

Re: Problems with JPA/Hibernate

#161

Post by earthboundkid »

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…

> How do you look for a person, if not based on his/her SSN?

These are different concepts. "Looking for a person" means search. You can look for people lots of ways. In medicine for example, they often look for first name + last name + birthday. Is that a unique ID? No, but it's close enough for search usually.

On the other hand, for any kind of indexing or foreign keys, you want an actually unique, immutable ID, which means you don't want a natural key, you want an artificial ID created just for your database.

Re: Problems with JPA/Hibernate

#162

Post by watwut »

eeperson wrote: post #146
watwut wrote: post #121

Earlier quoted context omitted.

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

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.

Re: Problems with JPA/Hibernate

#163

Post by deeg »

oulu2006 wrote: post #106
deeg wrote: post #79

Earlier quoted context omitted.

Shameless plug : for a little while now I've been working on a project with others to try a different approach. We use a higher level abstraction that does a better job of modeling the data than language-level objects. This eliminates the impedance mismatch. Because it's not language dependent you can use the same models (we call them "logical objects") with multiple languages. The logical objects are hierarchical an…

Nice, had a poke around, found a small typo while reading about it Asynchronous loads are trivial with Zeidon. Simply add the “.synchronous” qualification to the activate.

Thanks! It's on the list :)

Re: Problems with JPA/Hibernate

#164

Post by imtringued »

doctor_eval wrote: post #90
de6u99er wrote: post #74

Earlier quoted context omitted.

Having managed myself multiple projects using various JPA implementations I think JPA is great for relational database driven applications. Some of my projects contained 150+ tables. I always use a combination of JPA and JDBC. And everything derived from a base object that comes with create and update timestamps and users, plus a uuid based id field. The trick is that while knowing what you are doing in regards of li…

JPA is OK (but only OK) if you don’t have anything other than JPA accessing the database but in our largest application (1,000+ tables) this was never going to be the case. We had plenty of experience with database design, that’s not the problem. But we found even in simple applications with a dozen tables, the generated SQL was suboptimal. For example, to delete the children of a parent row resulted in a DELETE stat…

How do you get 75% fewer LOC without using JPA or Hibernate?

All I have to do to create a new table is define a class with some attributes and the corresponding SQL migration, I don't even have to annotate anything. To create a new row I just do new Table(attr1: expression1, attr2: expression2).save() and I am done.

Compare that to the usual mess of writing down the same column name four times with raw SQL (1. to reference the column, 2. to set the column value with a named parameter, 3. to set the named parameter, 4. declare the variable you wanted to save in the first place).

Of course, I'm not using Hibernate directly, that would be foolish. Instead I am simply using Gorm to wrap the awful parts of Hibernate (the irony).

Re: Problems with JPA/Hibernate

#165

Post by imtringued »

jillesvangurp wrote: post #126
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 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.

Re: Problems with JPA/Hibernate

#166

Post by imtringued »

the_af wrote: post #8

The underlying problem is one of O-R impedance mismatch. Going full SQL and getting rid of the ORM is a possible answer, but it has tradeoffs and is not a silver bullet. It might mean re-creating from scratch an in-house, bug-ridden ORM, or ditching OOP idioms from your language, or both. The author of TFA seems to be going through one of the stages described in "ORM is the Vietnam of Computer Science", an article th…

I don't believe that to be the case. The vast majority of applications built on top of ORMs design databases so that they are easy to map to. Sure, as soon as you access a database that wasn't designed for the ORM you run into trouble but this is an all or nothing problem. Getting rid of the ORM where it works doesn't actually provide you with a benefit.

Re: Problems with JPA/Hibernate

#167

Post by tablespoon »

doctor_eval wrote: post #113
tablespoon wrote: post #107

Earlier quoted context omitted.

> But we found even in simple applications with a dozen tables, the generated SQL was suboptimal. For example, to delete the children of a parent row resulted in a DELETE statement for each child row. I’m sure there are loads of good reasons why it did that, but it’a not something that you’d even consider in pure SQL. IIRC, it does that if you use Lists instead of Sets. https://dzone.com/articles/best-performance-pra…

Pretty sure I would have used a list, but making the Java interface ordered surely doesn’t change the semantics of the underlying relation?!

> Pretty sure I would have used a list, but making the Java interface ordered surely doesn’t change the semantics of the underlying relation?!

Yeah, it seems a little bonkers on first glance and I haven't ever dug in to see if there was a justifiable reason or not.

IIRC, if you just need ordering, you could just use an SortedSet. I think technically lists are for when you need ordering and duplicates.

Re: Problems with JPA/Hibernate

#168

Post by tablespoon »

watwut wrote: post #122
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…

Yeah, I don't hate JPA/Hibernate. I fact, I tend to hate its absence, because for me that's usually meant a four user CRUD app written with JDBC and a billion lines of boilerplate mapping between the domain and SQL CRUD statements.

I mean, there are definitely cases where JPA/Hibernate doesn't fit for all kinds of reasons, but don't avoid it where it does help (e.g. the 4 user CRUD app that needs to be "web scale").

Re: Problems with JPA/Hibernate

#169

Post by eitland »

doctor_eval wrote: post #156
eitland wrote: post #124

Earlier quoted context omitted.

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: ind…

I don’t think my point was sloppily written, but perhaps you misunderstood it. JPA is conceptually incapable of automatically utilising the structure of the underlying database (despite the fact that the database structure is actually dynamic), so it makes up for it by requiring you to write these huge entity models which declare - and duplicate - that structure. You effectively “throw away” the database structure be…

I might start to get what you are hinting at. Still the

> JPA is conceptually incapable of automatically utilising the structure of the underlying database (despite the fact that the database structure is actually dynamic), so it makes up for it by requiring you to write these huge entity models which declare - and duplicate - that structure. You effectively “throw away” the database structure because you have to rewrite it in Java/JPA.

The way you wrote it: "you get to throw away" made it seem like you have to throw away your knowledge. (emphasis mine)

What you describe above is easy to read, but is of course not "throwing away" but duplication, which is of course an issue, but a totally different one.

> I mentioned indexes but that’s just a side issue.

Is indexes an issue with JPA or not? ;-)

You (or others) might wonder why I pick at your comment but I am so tired of seing people choosing inferior solutions because people are scaring them away from what would be perfect solutions for them.

Re: Problems with JPA/Hibernate

#170

Post by TheRealDunkirk »

AaronFriel wrote: post #65
jacques_chester wrote: post #56

Earlier quoted context omitted.

> I think that the TechEmpower benchmarks suffer from many of the same problems the language benchmarks game benchmarks do - micro-optimization, unrealistic workloads. ... It takes more compute spend for a workload written in Java than one written in Go, all other things being equal. Well which is it, then? You say Java is slower, the benchmarks say otherwise. What other benchmark would you accept? I hate autoboxing…

I think that if all you're doing is serving the results of plain SQL queries, which is what the TechEmpower benchmarks are, then it's really hard to pick a bad language. Almost every language is capable of tens of thousands of requests per second. Even Ruby, a language we haven't brought up and is dreadfully slow, will do thousands of requests per second with Rails. Beautiful language, abysmal performance (relative t…

> Even Ruby, a language we haven't brought up and is dreadfully slow, will do thousands of requests per second with Rails. Beautiful language, abysmal performance (relative to what's possible).

It's precisely this terrible performance that makes ActiveRecord so much easier to program and better to use than Hibernate (or EntityFramework). I've written over a dozen Rails apps over the past 15 years, and it's "abysmal" performance has never been a problem for me. For my problem space(s), I'd make that tradeoff every day of the week, and twice on Sunday.

Post reply on HN