Hacker News Reader

Comment by sevensor | Hacker News Reader

I'm not really a web guy, so perhaps I was never the target audience for ORMs. I was surprised by the author's assertion that they seem simple and elegant at first -- maybe it's because I learned SQL first. My first impression of ORMs was, "this looks impossible to do right, in general, and basically untrustworthy. If it's going to work at all, you have to impose harsh limitations on both the 'object' side and the 'relational' side." Having read the article, I'm feeling pretty self-congratulatory. Other than claims to "elegance", what was the motivation for ORMs?

View on HN

I'm the last person to want to really defend ORMs. But there's a flavor of Greenspun's Tenth Rule [1] that applies... it would go something like "Any sufficiently complicated database-using app has a buggy implementation of half an ORM with major cache-consistency problems, some broken/outdated assumptions about the schema, and a few SQL injection holes you could drive a truck through."

A decent ORM can help manage the impedance mismatch between SQL and the app language. ORMs are very leaky abstractions and definitely restrict design, but metaprogramming SQL in an app language has its own drawbacks.

[1] https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule

This has been my experience as well. Being very comfortable with SQL, I initially thought very poorly of ORMs, especially given that my first major exposure was to a "buggy" half-hand-baked implementation. But, like a lot of other things, they definitely exist for a reason and can often be the best option given the particular tradeoffs you're given.

That's my experience with a certain 10+ year old piece of PHP enterprise software. Not only is the ORM homegrown, but it started as a data-mapper and somehow ended up being used in a degenerate way like active-record, and has lot of "fun" quirks.

>"Any sufficiently complicated database-using app has a buggy implementation of half an ORM with major cache-consistency problems, some broken/outdated assumptions about the schema, and a few SQL injection holes you could drive a truck through."

Inherited a product that used an ORM. The application was a java application running on multiple hosts and non-sticky sessions. It used session caching, which round-robin load balancing broke silently. Hah, no I'm kidding! It used global caching! Then it was replete with transaction annotations, but it was the wrong transactional level and the transactional annotations were not configured to be used anyway. Then the schema was hard-coded (which I'd usually say is a good thing) because they'd had the database fall over when the ORM attempted to update the schema. Of course the hard-coded schema was missing things and only fixed when the, now manual, updates to the DB caused the queries to outright fail. While the ORM prevented SQL injection, the belief that the ORM somehow handled any kind of injections, meant that the outputs weren't sanitized and XSS injections were not handled at all.

So perhaps the problem isn't SQL or ORMs, its that some programmers don't know what the fuck they are doing, and ORMs make it easier to postpone that enlightenment, sometimes indefinitely.

Coming from c# and using Linq:

1. Type safety instead of magic strings

2. Composibiity of queries.

3. Testability - I can mock out the dbcontext in unit test and use an in memory List<T> to test queries without having a database dependencies.

But these days, for any new project, my default is to avoid relational databases unless there is good reason for them. Even for BI, my live database is more than likely going to be NoSql and use a combination of CQRS, Event Sourcing, and messaging.

ORMs are essentially abstracting relational data structures to fit an OOP development style. It allows OOP engineers to access a DB without straying far from their comfort zone.

That's the sales pitch. In essence, they are rarely ever a good idea. As database drivers have become more simple to manage, and ORM's have tried to become more complex, the value proposition (which I'm loath to suggest existed in the first place) dissipated without any trace.

Yeah, SQL mapping frameworks, like MyBatis, seem to be the pragmatic sweet spot for most use cases.

Wikipedia:

> MyBatis is a Java persistence framework that couples objects with stored procedures or SQL statements using an XML descriptor or annotations

IOW an ORM.

> In essence, they are rarely ever a good idea.

I'm not sure I agree with this. There is a massive benefit to having not just your entire engineering org thinking in an object oriented fashion, but also your entire product org. Designers and PMs having a deep understanding of the data model is extremely useful, and to the extent that everyone is already speaking in OO terms (ie: your records are already going to be structured in this fashion), an ORM makes a ton of sense.

Not only does it give you abstracted and simplified syntax for common access patterns, it gives you a shim to add in all kinds of stuff like caching, analytics etc., that would be extremely difficult without an ORM.

Of course there are pitfalls, mostly poorly constructed queries that don't perform well, but any ORM will let you write raw SQL when you need to.

If your models map 1:1 to database tables it's hard to see why you wouldn't want an ORM, and I think there are a lot of great arguments for structuring your data like that (and of course some against it as well).

>>I'm not sure I agree with this. There is a massive benefit to having not just your entire engineering org thinking in an object oriented fashion, but also your entire product org. Designers and PMs having a deep understanding of the data model is extremely useful, and to the extent that everyone is already speaking in OO terms (ie: your records are already going to be structured in this fashion), an ORM makes a ton of sense.

Whether you use an ORM or not, your data layer can (and generally should) be designed to present a logical data model that may differ from your physical model. While some ORMs offer easy hooks for the addition of caching and analytics, the same is true for a well-designed data layer. I've also seen naive ORM implementations of those kinds of features cause more trouble than they were worth.

>>Of course there are pitfalls, mostly poorly constructed queries that don't perform well, but any ORM will let you write raw SQL when you need to.<<

While this is technically true, many ORMs force you into database access patterns such a multiple synchronous roundtrips to the database that do not perform well and cannot be resolved simply by dropping to raw SQL. A highly performant data layer is going to interact with the database in ways that ORMs generally cannot.

> While this is technically true, many ORMs force you into database access patterns such a multiple synchronous roundtrips to the database that do not perform well and cannot be resolved simply by dropping to raw SQL. A highly performant data layer is going to interact with the database in ways that ORMs generally cannot.

No, lack of thought in using the tools isn't the same as the tool forcing you to do it. Put the complex and efficient query into a view and map the view with the ORM, problem solved and SQL used appropriately and the ORM used appropriately.

You completely disregarded all of the organizational and communicative benefits I mentioned in favor of performance. Sometimes that will be the right choice to make, sometimes (I'd argue frequently) it will not.

> A highly performant data layer is going to interact with the database in ways that ORMs generally cannot.

This is not true, unless using the data layer instead of ORM allows you to structure your data differently. In which case, sure.

If your application has objects, and talks to a relational database to marshal result rows into instances of those objects, you are using an ORM.

As bgribble said above about Greenspun's Law as applied to ORMs.

> ORMs are essentially abstracting relational data structures to fit an OOP development style. It allows OOP engineers to access a DB without straying far from their comfort zone.

Not remotely correct; the purpose of an ORM is to map result sets into objects to avoid repetitive hand coding of those mappings for programs that work with objects. It isn't' about a dev's comfort zone, it's about eliminating the need to hand write repetitive mapping code.

> In essence, they are rarely ever a good idea. As

Also wrong, they are nearly always a good idea as they drastically improve productivity by eliminating tons of manual code that simply isn't necessary to write.

You don't seem to understand the value proposition of an ORM enough to be able to critique it.

And so the debate rages on...

There are two sides to this, illustrated by the parent post and you post. Ultimately, it comes down to style preference and his little actual tangible TECHNICAL benefit. The benefits to team process/organization can definitely be argued for ( or even against ) but, that is why the debate will rage on for eternity, IMO.

If there were no tangible technical benefit ORM's wouldn't be popular. The debate rages on because ORM haters like Climate Change deniers, rarely understand that which they critique. The debate exists because one side is ignorant and cant' tell the difference between using a tool in the wrong situation and a bad tool. ORM's are a great and useful tool and drastically reduce hand written and duplicated code; period, this is a fact and is not debatable. That in some cases they can be misapplied and cause problems doesn't make the tool bad, but it does feed anecdotes that ORM deniers like to pretend is all that exist.

The debate is stupid because one side is taking an absolute position against a programming tool that has been used successfully by thousands(millions?) of projects.

The funny thing about the anti-ORM-ists position is that they are either:

1) Exclusively embedding raw SQL in their code, and accessing each query result by also hard-coding column names and value types in map look-ups. Maybe this is a "pure" approach, but it is also very brittle as models evolve.

Or,

2) They develop their own naive ORM implementation without the self-awareness to realize that is what they are doing. As zzzeek said, "If your application has objects, and talks to a relational database to marshal result rows into instances of those objects, you are using an ORM."

The debate is stupid because one side is taking an absolute position...

Look, I don't have a horse in this race, so let me tell you that, from the outside, it's not so clear which side is being more unreasonable. Or maybe it is.

Edit: just to add something tangible, you're misrepresenting others' position too much.

This is completely correct and is the explicit stated rationale for the SQLAlchemy ORM which the original post refers towards (and of which I am the creator of).

One motivation, especially with a code-first work flow, is tying source control and db versioning together. With Entity Framework, you can downgrade the DB structure back to a specific point in time.

Versioning a database schema is orthogonal to the use of an ORM even though EF is an ORM that also facilitates database schema versioning.

Reply on news.ycombinator.com