Hacker News new | past | comments | ask | show | jobs | submit login

Hibernate didn't ruin his career, SQL did. If he'd actually worked with Hibernate, rather than abandoning it for SQL at the first opportunity, he would have got a system that performed well for less effort, was database-independent (which makes it easier to e.g. have a better test suite, because you have a wealth of in-memory options for testing so you can afford to run more tests on each build) and was more maintainable. All too often I've seen it play out like this:

1. Hibernate system working great

2. Idiot notices that one of their queries is slow, blames Hibernate

3. Idiot writes their query in raw SQL because hurr durr SQL is faster than Hibernate. (Bonus points for never benchmarking anything. Extra bonus points for switching to SQL and adding an index at the same time, observing this makes it faster, and deciding it's probably the switch to SQL that made the difference)

4. Idiot notices their query is getting results that are inconsistent with recent changes that went via Hibernate.

5. Rather than making any effort to fix this properly, idiot disables all caching in Hibernate. There, I fixed it.

6. Idiot notices that Hibernate queries are now slow (gee, ya think?) and uses this as a reason to migrate all other queries to raw SQL.

Hibernate doesn't save you from having to design a good data model, nor from having to tune it for performance. You can't turn off your brain when using Hibernate, you do still have to figure out which entities own which side of their relationships, and when you get to a scale where performance becomes an issue you do have to spend a bit of time doing performance tuning, just as you do when using SQL. It does genuinely simplify a lot of things and save you from writing a lot of boilerplate. But if you spend a week tuning your SQL query and no time tuning your Hibernate query and use that as your benchmark, no shit the SQL will be faster, and if your first resort whenever you hit a slow query is going to be to bypass Hibernate rather than working with it then yeah you probably shouldn't be using Hibernate in the first place.

My favorite "hibernate is slow" story, actually nHibernate in this case, was at a company that was storing the second level cache in session variables. Half the database was being deserialized then resirialized into the session storage on every request. It also completely destroyed any consistency the second level cache would have provided, because session variables are per user.

By reading this I have the feeling it's like saying "You have to know every technical part of your car in detail before you drive it". I'm thinking that in a complex project you don't have time to do that... some people just want to drive but not think about it too much. Seems Hibernate has too many pitfalls if you are in hurry to develop something and you are not doing performance measuring (and beeing able to tune it) in every step of development.

So don't use Hibernate if you are not an Hibernate expert?!

For a fixed amount of effort, you'll do better with Hibernate than without. But if you're an SQL expert and a Hibernate novice you should probably stick to SQL, or else accept that you're going to have to take some time learning (just as if you were to start using e.g. Cassandra you wouldn't expect to immediately be as effective with it as you were with SQL).

And don't expect to mix SQL and Hibernate operations freely in the same code, any more than you'd expect to freely mix e.g. encoding-aware String operations and manipulation of the underlying bytes. It's possible to make good use of the fact that Hibernate is implemented in SQL, CQRS-style: use Hibernate for your "live" operations in your application, use SQL for reporting/aggregation and ad-hoc querying, playing to both their strengths. But don't try to interleave them, especially in the same transaction.

No, don't use Hibernate if your solution to ignoring your tools is writing your own half-assed workarounds rather than take the time to read documentation and ask the right questions.

People do this with SQL all the time; they see queries that aren't "fast enough" and they add indexes everywhere, or they "nudge" the query planner the wrong way, or anything else than to accept that maybe their data was wrongly modeled in the first place, or maybe they need to remove indexes, or actually, you know tune the DB.

Your spirited defense of ORMs reminds me of JWZ's XML rant. Punchline: Now you have two problems.

How is any of this a counterargument to the article? And the hypothetical developer in it is a woman. And in their (again, fictional) scenario, they struggled with Hibernate for four years.

> And in their (again, fictional) scenario, they struggled with Hibernate for four years

In their fictional scenario they didn't learn to use hibernate or SQL.

>And the hypothetical developer in it is a woman.

Don't assume their pronouns!


The developers in the article make the same mistake - using native SQL "for performance" instead of working with Hibernate.

I read the title as referring to the (male) author's career; I understood him to be telling his own story through these hypothetical characters.

Hi (author here). This story is purely fictional. :). As a freelancer I was in many cases forced to fix some Hibernatish chaos or work within fixed technological stack where Hibernate just cross the limits of stubbornness. I don't want to say it's bad technology, just compiled some thoughts and experience of many people (including myself) into the story. Thanks for reading :)

Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact