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

71–80 of 195 posts

Re: Problems with JPA/Hibernate

#71

Post by dopidopHN »

karmakaze wrote: post #22
The_rationalist wrote: post #18

Earlier quoted context omitted.

Nothing prevents you from using raw SQL queries with Hibernate. HQL is just a convenient superset.

Actually mixing raw queries with JPQL/Hibernate queries is the worst of all worlds. To get it right, you will end up making explicit calls to let the EntityManager know what you want each side to be doing to play nice.

I've seen that a lot in the past 10 years, and I don't find it particularly problematic.

Often the fucked up native query end up in a different type of DAO for performance / concurency reasons anyway.

Don't get me wrong, I dislike JPA and Hibernate really much, but that particular aspect has often been one of the less painful to deal with.

Re: Problems with JPA/Hibernate

#72

Post by cletus »

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

Man, you and I see eye to eye here.

I'm a firm believer in leaky abstractions [1]. I often found with JPA that I would be fighting the framework to get it to produce the SQL that I wanted. I encountered (then) ibatis and it was a breath of fresh air. It took care of much of the tedious column-to-Java mapping and didn't introduce another DSL.

As soon as anyone tells you "you don't need to learn X with our framework Y that sits on top of it", all that means is you have to learn X, Y and the X->Y and Y->X translations and all but the first is proprietary.

This was my core issue with GWT (Google Web Toolkit) too. Too many engineers who weren't interested in learning Javascript saw it as a way of avoiding learning Javascript.

It's been many years at this point since I've used it so this may have changed but I recall that query verification was a runtime error issue and there wasn't a good way to essentially check that all your queries were valid. I mean you could write this yourself but it seems like some CI/automation could've done a lot of the heavy-lifting.

IIRC the same went for integration testing and stub databases for reading and writing via ibatis/mybatis.

[1]: https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a...

Re: Problems with JPA/Hibernate

#73

Post by hagy »

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've found jOOQ to provide the right tradeoffs and flexibilities for ORM vs. SQL. First, it can generate object models of tables from the database in development and therefore doesn't rely on any specific migration tool. These model classes can be used in a conventional ORM fashion, but you also have the option to use jOOQ to build SQL queries.

You can even fetch the results of arbitrary SQL expressions into a model class, which can handle partial population of columns. This allows combining ORM and SQL approaches with some code operating on models where that is natural, but this code can be applied to models which are fetched in alternative fashions when that is more preformat. E.g., fetching records using criteria that involves joins and only selecting relevant columns for the subsequent processing of fetched results.

The jOOQ "DSL" (i.e., Java interfaces and static methods) gives you essentially the full power of SQL without having to rely on external SQL files or stored procedures. (Or even worse strings.) You can even programmatically build these queries. E.g., optionally including different WHERE/HAVING criteria. The jOOQ "DSL" provides a fair amount of compile-time type safety, which isn't possible with external SQL.

Re: Problems with JPA/Hibernate

#74

Post by de6u99er »

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

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 limitations and performance, you design the data model alongside cardinalities from user facing components. You'll end up with a highly normalized schema.

The nice thing is that you can create views later on and transform data into shapes that are more useful to others.

If you make the mistake to start with the data-model only without knowing how the data is being collected or used you will most likely spend lot's of time converting entity objects into other objects and the other way around. The worst thing I have seen in my career, was half of the business logic implemented in Java and the other half in PL-SQL.

JPA is great for large projects! I haven't had a single issue that we could not solve.

Re: Problems with JPA/Hibernate

#75

Post by alserio »

vips7L wrote: post #53
eeperson wrote: post #50

Earlier quoted context omitted.

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

If you have a managed instance of an entity, like something returned by a find or a query, calling a setter will modify its state and the state change _will_ be detected and persisted automatically on the next flush, without explicit persist or merge.

Re: Problems with JPA/Hibernate

#76

Post by lmm »

jacques_chester wrote: post #24

I largely agree that JPA is a maddening mess[0]. However, this sentence caught my eye: > I love open source, really, but big companies sponsoring open-source projects get most of their income from support or third party tools. I work for VMware and consequently take some interest as to how my salary comes into being. If you think VMware makes "most of its income" from supporting Spring, then I think I'd encourage you…

> If you think VMware makes "most of its income" from supporting Spring, then I think I'd encourage you to spend some time at the investor relations site[0] reading any of the annual or quarterly reports.

VMware is a huge company with its fingers in many pies, but I suspect if you rewrite the sentence as "most of their income attributable to that open-source project" then it would be true of such companies. Presumably VMware sees a return on investment for its sponsorship of Spring (otherwise why do it?); if that's not coming via support or non-free tools that build on Spring then where is it coming from?

Re: Problems with JPA/Hibernate

#77

Post by alserio »

victor106 wrote: post #30

Just because you're using Hibernate doesn't mean you have to use it for everything —Gavin King, creator of Hibernate Source:- https://twitter.com/markuswinand/status/456827165938434048?s...

"But then say goodbye to the consistency of your second level cache" - Gavin King, probably

Re: Problems with JPA/Hibernate

#78

Post by alserio »

eeperson wrote: post #58
cle wrote: post #29

Earlier quoted context omitted.

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

Re: Problems with JPA/Hibernate

#79

Post by deeg »

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…

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 and serialize easily to JSON and back, making it simple to write REST interfaces. There are a couple of production teams making good use of it.

Github repo is here; feel free to contact me about it: https://github.com/zeidon/zeidon-joe

Re: Problems with JPA/Hibernate

#80

Post by lmm »

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 of your database is writable. The impedance mismatch is big enough already without trying to make objects that behave differently from your database. Yes, an object shouldn't just be a datastructure with methods; unfortunately an SQL table row is just a datastructure, and classes are the only mechanism Java offers for representing such a thing. Same for mutable collections.

Reflection (which is the reason classes must be non-final): again, sucks, again, the only way to do something like this in Java.

Lazy loading is wonderful. Put your session in your view, write a normalised set of entities that actually model your domain, and get on with your life. Don't worry about the details of what loads when unless and until you have to.

Those who don't understand Hibernate caching are doomed to reinvent it poorly.

Don't use your database as an API. Yes, Hibernate/JPA needs to own your database. That's as it should be. SQL databases are way too complex to be shared between independent applications.

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?

None of the problems listed here are problems of JPA/Hibernate. They're problems of SQL databases which are surfaced through JPA/Hibernate, but if you skip out on JPA/Hibernate you still get exactly the same problems (maybe in a slightly less recognisable form). The real solution is to stop using these overrated datastores, but if you must use them then JPA/Hibernate is the least-bad way of doing so.

Post reply on HN