
The ORM Debate Still Rages On - code_pig
http://robbygrodin.com/2017/04/18/wayfair-blog-post-orm-bankruptcy/
======
ungzd
He is writing it as if ORMs are only for allowing to do queries without
knowledge of SQL syntax (which is weird idea) and for forcing database to fit
into OOP mindset.

SQL (in strings) is not composable at all. Your app rarely has fixed set of
queries and almost always need to be able to construct 'where' dynamically,
add joins, etc. SQL syntax is especially non-composable, because there once
was hype to make programming languages imitate natural languages. In this
case, ORM is inevitable if you don't want to have rube goldberg machines of
string concatenation everywhere.

Non-OO ORMs may be not called "ORM"s but idea is the same. Moreover,
Sqlalchemy Core mentioned in article is great example of non-OO ORM: it
composes queries and returns result in tuples[1].

[1]
[http://docs.sqlalchemy.org/en/rel_1_1/core/tutorial.html](http://docs.sqlalchemy.org/en/rel_1_1/core/tutorial.html)

~~~
wvenable
The composability of ORM queries is a huge benefit to organization and
readability -- but not all ORMs handle that well.

The article makes a good point; I never think of an ORM as a replacement for
SQL -- it can work in concert with it. A lot of my code is much simpler with
an ORM than it would be worth out it and in other places it's much simpler
with direct SQL than without it. Both can live together harmoniously.

~~~
fergyfresh
EXACTLY. You can drop into SQL in many ORMs and you use that sparingly as it
is much nastier to maintain nuances when switching between different SQL
implementations like MySQL and PostgresQL, for example.

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

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

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

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

~~~
runin2k1
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."

~~~
narag
_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.

------
secstate
I think the biggest problem with polemic blogrants like this are that the
author has encountered their own personal bankruptcy with ORMs and proceeds to
indict the entire enterprise of mapping an object-oriented language
environment to a relational object environment.

Suggesting that ORMs are awful and no one should use them is effectively
premature optimization, and we all know the consequences of that.

It is also actively ignoring the history of ORM development. Django's ORM, I
know for instance, was developed at a newspaper so that you could go from
"feature writer has giant data set and interesting idea about how to visualize
it" to "production interactive newspaper article up and allowing people to see
their community from different vantage point" within the scope of a day or
two. And it worked. And it continues to work.

Ignoring the functional aspects of the world or proscribing premature
optimization with your opinions is effectively soapbox ranting. You can do it,
but the solutions and equity being built on the backs of shitty SQL generated
by ORMs are going to just walk right on by.

~~~
astrodust
"I painted myself into the corner of a room. Clearly the roller is at fault!
This would never have happened with a brush!"

People who bitch about ORMs usually complain for the wrong reasons. Many ORMs
are highly opinionated about how to organize their tables, and if you don't
adhere to that your code complexity can climb exponentially. If you're
constantly going against the grain, maybe you're using the wrong ORM.

Keep in mind even ActiveRecord, as ornery as it can be, still has a "revert to
manual query" mode. Any well-designed ORM should support that as well.

------
fergyfresh
From what I know about using both it seems like MANY of the benefits were
missed. With ORMs you don't really need to worry about database connections or
specifying stuff like that. You can also make functions that execute pure SQL
in ActiveRecord which I've done before and is in Michael Hartl's Ruby on Rails
tutorial. You can also switch between different SQL implementations without
worrying about having to refactor stuff, as its usually just an initial
configuration/migration. I am not entirely sure but this is from medium so I
usually take anything tech related on medium with a grain of salt. If you
don't have your tables set-up right you're going to have to do a bunch of
weird table joins and stuff, but you can also look into fixing ur databases.
DATA STRUCTURES AND TABLE ORGANIZATIONS ARE KING.

------
elchief
Use an ORM for CRUD, and use a SQL library (like Jooq or QueryDSL for Java)
for custom querying

~~~
tomschlick
Exactly. Everyone wants a perfect solution for multiple use cases and that
simply doesn't exist. Use what works for the task at hand.

For example, Laravel's Eloquent database layer is awesome for the 95% use
case. When stuff gets complicated I can drop down to the query builder or raw
SQL if things get real hairy.

------
diminoten
I intuitively feel like, in $CURRENT_YEAR, this problem comes up mostly for
the people who look for it to be a problem.

I work with Django's ORM on a daily basis, and I think being aware of the fact
that I can't completely ignore how I interact with my database (e.g. "Well I
have an ORM so I shouldn't care" <\- this is bad) is enough. The idea that I
throw out the proverbial baby here feels like an overcorrection, and while I
get how complicated an ORM can become, I think that's more of a result of
relying too much on the abstraction.

I'm sure most folks here are familiar with Joel Spolsky's "Leaky Abstractions"
article. The way I see it, the ORM abstraction is leaky, and that's okay,
because the alternatives are all so involved and complex. For some higher-
than-fifty percentage of the time however, the abstraction works. That has
value.

------
default-kramer
My biggest problem with ORMs is that you have an object graph that may or may
not contain proxies. When you hit a proxy, the ORM will either do a lazy-load
or throw an exception. Neither of these is a good default. Either way, the
type system becomes useless, and I have to manually check all the call stacks
to make sure the object graph is actually loaded.

... but I'm still getting good use out of an ORM right now. I use Entity
Framework for the write operations (with lazy-loading) but hand-written SQL
for the reads. It works better than anything else I've tried in the past.

------
dustingetz
Object/relational impedance mismatch is solved by a new class of database
built on immutability. If the storage segments are immutable (like git), the
query process can be moved out of the central transaction processor and into
the horizontally scalable application process (like git). When query engine is
embedded in the application process, all the latency and network round trips
drop out (like git), which solves in one fell swoop all the intractable
optimization problems that ORMs attempt (and fail) to abstract away. One such
database is [http://www.datomic.com/](http://www.datomic.com/)

edit: these databases are relational, acid and competitive with postgres.
Strong consistency is achieved by threading through a notion of time (like
git)

i wrote about it on reddit once, here:
[https://twitter.com/dustingetz/status/690374292027117568](https://twitter.com/dustingetz/status/690374292027117568)

~~~
gnaritas
That doesn't solve the ORM problem at all. Using a non relational database in
no way solves the relational object impedance mismatch; it's frankly
unrelated.

------
vinceguidry
ORMs are like any technology choice, they allow you to get by with less-
skilled engineers. You have to work with the tools you are given, and if the
only readily-available devs to hire in your area are all .NET guys, guess what
your tech stack is going to look like?

Trying to make these decisions based on the merits of the techs themselves
doesn't derisk the business, it does the opposite.

~~~
diminoten
I think the problem people have with ORMs includes the fact that it _seems_
like it should let you get away with less-skilled engineers, but the more
skilled engineers know that the ORM doesn't save nearly as much time/knowledge
as it appears to.

It's true, you can have a junior person write up a view simply using the ORM
as it appears, but then during code review it'll be valuable for the senior
person to come in and say things like, "That query is going to suck, here's
how you'd get that data without locking so many tables."

~~~
gnaritas
If any of your queries are locking tables find a better database; what a
senior would do is look at the query log and say hey, you've got an N+1
cascade load issue causing this to be so slow, optimize the query to prefetch
the sub data or create a view that has the data you need already and map that.
Cascade lazy loading is usually what makes an ORM perform badly and it's
merely an indication the dev has a query to optimize, not a sign the ORM is
broken.

