Hacker News Reader

Comment by stickfigure | Hacker News Reader

> I'd rather learn SQL than whatever custom-flavor-of-ORM-query-language some ORM tool created.

Me too! That's why I use an ORM that lets you write queries in SQL, like... Hibernate.

This narrative seems to come up frequently. People make (good) arguments against certain features of ORMs and then conclude it's an argument against ORMs in general. The boundary between databases and codebases is very broad. But ultimately you work with objects in your code, and relational tables in your database, so there's going to be some sort of Object Relational Mapper in between.

View on HN

> Me too! That's why I use an ORM that lets you write queries in SQL, like... Hibernate.

Yeah, this criticism of ORMs strikes me as off-base. I feel like any ORM worth its salt gives you the tools to write raw SQL as needed, which can also be combined with the query builder the ORM uses.

I use Rails/ActiveRecord and have very few complaints. When I need to do something simple, the convenience methods work great. When I need a complex query, I just write it.

There's a learning curve here, where you have to understand when to "break glass" for writing queries directly (either for better performance reasons or because an ORM lacks the expressiveness required).

I think a lot of ORM hate comes from people who never got deep enough to really hit the sweet spot. They (correctly) note that the ORM abstractions aren't suitable for every query, but (IMO) they disregard the benefits that they provide for most queries. If something like 90% of my queries can be generated by an ORM, I'm feeling pretty good about that - it's a lot more maintainable.

> I think a lot of ORM hate comes from people who never got deep enough to really hit the sweet spot.

This. And also, the feel of using Rails/ActiveRecord resonates with me in a way that no other ORM I've used does. It's not just the ORM but the tooling around it esp. wrt generating migrations, scaffolding and so on.

> There's a learning curve here, where you have to understand when to "break glass" for writing queries directly.

Yep. ORM is a tool. The craftsperson needs to acquire skill both in using the tool and in knowing when to reach for another tool.

Maybe some people feel ORM is never the right tool. Who can argue with that? I'm curious to see how they do it. Maybe I'll learn something.

> ultimately you work with objects in your code, and relational tables in your database

Yes, you can map a record in a DB table to a class, and as long as you are happy with retrieving records (and related records) and mapping them to classes, an ORM will be all you need. But SQL is not just limited to the columns of a table, you can join, define new columns in your select statement, group, use aggregate functions etc. etc., and then you quickly get into territory that the ORM doesn't understand anymore. So the point that ORMs take away a lot of the flexibility that SQL gives you still stands...

This is not an objection to ORMs, except perhaps very simplistic ones. The ORMs I'm familiar with let you map queries to arbitrary objects. I use CTEs, joins, groups, aggregations, custom columns, etc in SQL queries (with Hibernate) all the time.

But... At that point what does hibernate even do for you? You can just use a lighter query wrapper at that point, or almost even roll your own wrapper around jdbc directly. The latter is a bit more work but it might be worth it depending on project since it gives you absolute control.

I'll take a query wrapper that's designed so I supply queries directly and it does the work from there (binding to objects) over using hibernate that way any time.

> depending on project since it gives you absolute control

Absolute control to hunt down your own bugs, instead of using something that is an industry standard and any competent programmer jumping to your project can be up-to-speed with it instantly..

Very few developers are competent with hibernate, many fewer than with sql. Writeback cache nature of hibernate makes it very complex, order of operations on the app won't match order of operations in the DB.

Even an "industry standard" framework can get in the way. Given the constraints of executing efficient queries; handling errors and timeouts on the application's terms; and enforcing concurrency and transaction handling policies even a "good" ORM can be more a problem than a solution.

All of those will be worse off by hand-made “solutions”. Especially that you are not forced to use ORM for everything. Use it for like 90% of your generic db usage, and use its in-built escape hatches for the rest, like native queries or go straight to the db driver if needed.

In my experience I‘m better off not touching an ORM at all

Having seen quite a lot of 'roll your own' solutions for wrapping queries: they were almost all unstable, inefficient messes that have a tendency to pick up lots of ad-hoc functionality. I'm not particularly fond of Hibernate but at least it's well tested and efficient for what it does and does things in a standard way so you can mostly look up stuff in the manual instead of guessing your way through a homebuilt framework.

Reply on news.ycombinator.com