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

This doesn't look like it was a problem with Hibenrate, more of a "wrong tool for the job"-scenario. Reposting what I recently wrote on Reddit on a similar Hibernate discussion thread:

In my experience, ORMs and specifically SpringData-JPA-Hibernate occupy this weird niche in the enterprise spectrum. They are an overkill for small projects and they become a hinderance for large projects, so they sort of sit there for medium projects. If you start with an ORM on a medium size project and it becomes a big project you can sometimes find yourself in an awkward spot where you are writing a lot of SQL (and not of the JPQL kind). With Hibernate/JPA specifically there are so many things that are broken that they just start getting in the way if your schemas become large enough. To me this is really just a manifestation of Behavioral Problem (Martin Fowler, Enterprise Patterns), where relational databases don't really map to objects at all when you get down to it.

Basically, if you are going to do quite a bit of SQL, any ORM will just in the way. Should be plainly obvious to anyone with experience.

It depends a lot of the ORM. SQLAlchemy allows you to ditch the ORM when you need it. But instead of going back to raw sql, you just get a DSL like LINK, which is very flexible and can express most of the stuff you could do with manual SQL, while still retaining many benefits of using a wrapper.

It's my understanding that Hibernate doesn't allow this.

> Basically, if you are going to do quite a bit of SQL, any ORM will just in the way. Should be plainly obvious to anyone with experience.

This is the problem you see : a lot of project don't have somebody very experienced with SQL anymore. Because they need to know a bit of sysadmin, and front en dev, and deployment, and CI, etc. So an ORM helps a lot in that regard, and will help most projects because the problems it causes are smaller that the ones it solves:

- it forces people to put the schema, migrations and validation code in a centralized place.

- it let you reuse your API knowledge instead of having to relearn the stuff for SQLite/Postgres/MySQL/Access.

- it enforces good practices on security with data escaping and cleaning.

- it let you benefit from your language tooling (analytics, linters, completions, doc, shells) to write queries that otherwise would be plain text in the middle of the file for most people.

- it gives a structure to DB operations, so if you look for something, you know where and what to look for.

- it gives you an event system to decouple queries and their effect.

- it gives a common API so you can write easily libs targetting the ORM. This is why the django ecosystem is so rich : you can write an auth backend or a tagging system and know other people will be able to just plug it in.

- it comes with tooling: auto generated admin, forms and APIs, migration manager, paginators...

It does have a cost in perf and sometime flexibility. But for anything that doesn't have 1 million of users yet, it's worth it. Especially in a world where a daily salary can be more than a year of server time.

I cache everything anyway :)

And it allows you to write specific queries that can then be post filtered / ordered / paginated by a more general mechanism.

Or you can write queries and play around with loading strategies later / change them over time as the shape of the data changes without having to change any other code.

Every time the ORM thing comes up on HN most people jump on the ORMs are evil bandwagon. I think sqlalchemy is probably a bit of an exception in terms of just how flexible it is, however in my experience you get all the benefits with next to no downside (performance overhead being the most obvious). I generally wouldn't start a project without it these days.

Applications are open for YC Summer 2019

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