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

51–60 of 195 posts

Re: Problems with JPA/Hibernate

#51

Post by simonw »

dale_glass wrote: post #43
yukinon wrote: post #40

Earlier quoted context omitted.

> Personally, I'm a fan of giving everything a random UUID, because it's more flexible Unless of course, you're using a relational database like OP and incur a performance hit from using a UUID as your primary key. Additionally, they're not sortable like autoinc id's. I've always wanted to try out Twitter's Snowflake ID [1] algorithm to get around this, but it requires requires using something like Zookeeper. I've se…

Things like Twitter are special. I'm talking more about a generally sensible way of doing things, which one may need to deviate from in special circumstances. Why would you want to sort by ID? Sort by something sensible, like the signup date instead. An autoincrement may stop corresponding to time if for instance at some point a database has an external dataset imported into it. IMO, using an ID for anything other th…

I like IDs I can read out over a call, or recognize when I spot them in a log file. The few times I've used UUIDs for IDs I've later regretted it.

Re: Problems with JPA/Hibernate

#52

Post by doctor_eval »

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). You get to throw away all the semantics built into the database structure, including knowledge about indexes, and you need to duplicate almost everything from SQL into Java, in the form of complex annotations against entity objects that you often wouldn’t need with traditional SQL access patterns. And when something goes wrong, you have a large, complex framework, including an inscrutable caching layer, between your code and your data - which can make debugging JPA code very challenging.

In return you get reduced performance, overly complex and difficult to read SQL code generation, an inflexible entity model, and non optimal database access patterns.

JPA is an extremely complex framework whose benefits, in my opinion, outweigh the costs in only a small number of relatively simple use cases. And even in those simple use cases, in my experience it is far less performant (and double the LOC) than using SQL directly.

I’m not saying you can’t use JPA in large, complex applications, because you obviously can. But those applications are harder to write, much larger, less maintainable and less performant than the equivalent applications written with simpler frameworks or libraries.

I personally found MyBatis annotated interfaces to be the ideal way to map SQL to Java, but perhaps ApacheDB is better for smaller projects.

JPA is one of those fabulous engineering experiments that, sadly, didn’t work out. It breaks every rule in the engineering book in order to make SQL work like Java, but it doesn’t succeed, and I could never recommend it to anyone.

Re: Problems with JPA/Hibernate

#53

Post by vips7L »

eeperson wrote: post #50
vips7L wrote: post #46

Earlier quoted context omitted.

> How the hell even hibernate caching works? Why even are there 2 levels of Hibernate cache? https://docs.jboss.org/hibernate/stable/orm/userguide/html_s... > using setter of an instance shouldn't update in database by default omg This doesn't happen.. the database won't update until you ask the entity manager to persist the entity. > I've seen one project where transaction leaked to Jackson!! Jackson was calling get…

> This doesn't happen.. the database won't update until you ask the entity manager to persist the entity. Doesn't this happen through automatic dirty checking?

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.

Re: Problems with JPA/Hibernate

#54

Post by vips7L »

Scarbutt wrote: post #42
SahAssar wrote: post #36

Earlier quoted context omitted.

There is https://en.wikipedia.org/wiki/Rhino_(JavaScript_engine) and https://en.wikipedia.org/wiki/GraalVM . The latter of those is the second fastest js server runtime (es4x) according to techempower benchmarks: https://www.techempower.com/benchmarks/#section=data-r20&hw=... I haven't tried any of those, but saying the JVM can't run JS is not true.

GraalVM is not a drop-in replacement for the JVM and Rhino is slow as molasses compared to V8.

> GraalVM is not a drop-in replacement for the JVM

As far as I understand, yes it is. GraalVM is just HotSpot with the graal jit compiler instead of C2.

Re: Problems with JPA/Hibernate

#55

Post by kleinsch »

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 biggest benefit is that you have a massive library ecosystem and developer base that understands it. If you’re going to throw all that out and require new people to learn your homegrown mess, why not pick a language that’s more interesting than Java? Then you’ll get new developers that are anxious about Go/Elixir/WhateverHotness.

Saying this as someone with 15 years in Java world.

Re: Problems with JPA/Hibernate

#56

Post by jacques_chester »

AaronFriel wrote: post #49
jacques_chester wrote: post #33

Earlier quoted context omitted.

> Which of the TechEmpower benchmarks uses an ORM? There are two: single query and multiple query.

Sorry, I should have been more precise. I am very, very familiar with the TechEmpower benchmarks and I first learned Java around SE 5, right after they switched from 1.x numbering. Please don't mistake me for someone who just learned about Go or Rust and is evangelizing them because I think they're the cool new thing. Which of the Java implementations for the TechEmpower benchmarks use an ORM? Are they representative…

> 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 as much as the next numerical processor, and I avoid JPA whenever I can, but that doesn't change that Java is plenty fast on a variety of workloads. It's typically only beaten by the hardest of the hardcore Rust and C++ implementations.

Re: Problems with JPA/Hibernate

#57

Post by KamBha »

I find this argument a little odd:-

"Frameworks do not keep retro-compatibility"

I would argue that is a good thing and in the case of Spring, doesn't feel true. In part, Spring is so hard to learn because it has too much support for legacy stuff (though this may have changed in the last few years).

The only issue with not supporting retro-compatibility is because the JVM doesn't support retro compatibility. I recently tried to upgrade an application to the latest version of Java (I think it was Java 12) and found that date formaters were completely changed to match an ISO standard which broke a lot of code. We also found a similar problem with the Java 8 transition as well forcing a huge upgrades to our libraries.

I am of the view that libraries and frameworks should support not support retro compatibility but the language should. This way, if you don't want to upgrade your library then you don't have to.

Using the web as an example, old Angular JS applications still work today as they did back when they were first written. I doubt applications written in the first version of Spring will work with the latest version of the JVM.

Re: Problems with JPA/Hibernate

#58

Post by eeperson »

cle wrote: post #29
eeperson wrote: post #20

Earlier quoted context omitted.

How is that a benefit specific to JS? Don't those platforms generally support Java as well?

They do but the Java ecosystem takes a hit here, with many libraries being slow to initialize. The slower it takes to startup, the longer it takes to absorb the new load, to the point where you either keep some headroom (IOW, waste $$$), or try to predict load (complex, also wastes $$$). There are attempts to fix this with e.g. Graal, which effectively does the expensive initialization and reflection at compile time,…

> 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 understand what the downsides are for Graal and FAAS. There are some pitfalls around reflection but even those don't seem to hard to avoid. Is that what you are referring to?

Re: Problems with JPA/Hibernate

#59

Post by mosdl »

simonw wrote: post #51
dale_glass wrote: post #43

Earlier quoted context omitted.

Things like Twitter are special. I'm talking more about a generally sensible way of doing things, which one may need to deviate from in special circumstances. Why would you want to sort by ID? Sort by something sensible, like the signup date instead. An autoincrement may stop corresponding to time if for instance at some point a database has an external dataset imported into it. IMO, using an ID for anything other th…

I like IDs I can read out over a call, or recognize when I spot them in a log file. The few times I've used UUIDs for IDs I've later regretted it.

Add a prefix to the if then.

Re: Problems with JPA/Hibernate

#60

Post by FridgeSeal »

tarkin2 wrote: post #39
api wrote: post #9

From my experience ORMs are good time savers when you have relatively simple query needs, but fall down when things get really complex.

And time. Let's not forget time. Years of Django's ORMs has given our app over a hundred tables. Complex and /fast/ queries are next to impossible. Django's ORM made app development lightening quick for the first developers. And impossible for the ones fives years later.

ORM’s and other frameworks should come with an “eject” command that once you run it, gives you all the raw SQL/generated config/etc etc.
Post reply on HN