Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

OrmHate

martinfowler.com

Post reply on HN
Print view View original

31–40 of 136 posts

Re: OrmHate

#31

Post by jerf »

RyanMcGreal wrote: post #7

> There is a lot of truth to these charges, but such charges miss a vital piece of context. The object/relational mapping problem is hard. I suspect that context is precisely what underlies the common critiques of ORMs. Those people who best understand the inherent object-relational impedance mismatch tend to be the very people who conclude that the effort isn't worth it. In my admittedly anecdotal experience, I have…

That's the view I've come around to. The more I learn, the more I see that the ORM problem isn't just hard, it's effectively unsolvable. They don't map. There is no such map. It turns out to be a general principle that just because something is basically impossible doesn't mean that you can't write code that sort of kind of does it mostly most of the time, but the usually when that happens you end up with an enormous endless tar pit of a mess that even after massive resource expenditure still has lots of quirky problems and doesn't really work. It's better to build your system on foundation that doesn't involve solving an impossible problem.

Another example: "Multitasking" in Mac OS prior to OSX. No amount of hackery can turn a cooperative multitasking system into a preemptive one... but you sure can make a big mess trying. There's a lot of other examples if you look around. Look for a big, endlessly-growing mass of code that never seems to stabilize no matter how many resources are poured into it, and you'll probably find it's trying to do something impossible deep down in its core.

Re: OrmHate

#32

Post by RyanMcGreal »

debacle wrote: post #15
RyanMcGreal wrote: post #7

> There is a lot of truth to these charges, but such charges miss a vital piece of context. The object/relational mapping problem is hard. I suspect that context is precisely what underlies the common critiques of ORMs. Those people who best understand the inherent object-relational impedance mismatch tend to be the very people who conclude that the effort isn't worth it. In my admittedly anecdotal experience, I have…

> Those people who best understand the inherent object-relational impedance mismatch tend to be the very people who conclude that the effort isn't worth it. You're showing a severe bias. > I have found that ORMs are the most useful for the most trivial queries. That's really what ORMs are for. Three joins, max. Any more than that and you really can't trust the ORM. It's a computer, after all, not a DBA.

In other words, ORMs are at their most useful when solving the least challenging problems. To which we must ask: why bother?

Re: OrmHate

#33

Post by moondowner »

columbo wrote: post #12

def user = User.findById(25) return user.getLocation().getAddress().getState() What happened during that execution? Was that 1 query or 50? Would it have been better to write a specific sql statement? To me, this describes the biggest challenges with using or not using ORMs. I don't think there is an easy answer.

At least in Hibernate, you can set to print the actual queries in console (or text file, depending how your logger is set).

http://stackoverflow.com/a/2538954/228692

That way, during development you can see which are the actual statements executed. I say during development because after that, in production, you'd be better off filling log files with these stuff :)

And I can answer your question (for Hibernate), that will be one query.

Re: OrmHate

#34

Post by narag »

I don't like the implementation of ORMs as run-time layers. I very much prefer using a tool that generates code. It's orders of magnitude easier to maintain... for me anyway.

Re: OrmHate

#35

Post by phillmv »

columbo wrote: post #12

def user = User.findById(25) return user.getLocation().getAddress().getState() What happened during that execution? Was that 1 query or 50? Would it have been better to write a specific sql statement? To me, this describes the biggest challenges with using or not using ORMs. I don't think there is an easy answer.

>I don't think there is an easy answer.

Uhm, ActiveRecord at least will print the SQL it generated. If you think it's inefficient, you can just… write your own sql that maps out to that query. With Arel/scopes, they're also composable and lazy loaded. What's not to like?

Re: OrmHate

#36

Post by andrewcooke »

latch wrote: post #21

Surprised by the pro-ORM comments so far. My hate for ORMs grew proportionally with my usage of NoSQL. It's such a pleasant experience when your domain model fits the data model. Graphs are a good example, but Redis is a better one. When your intention fits a Redis data structure, it's just programming bliss - a few lines of explicit and simple code. The only way I can use a relational database now is with Sequel.

it depends so much on the context. i work with a wide range of different technologies. when i'm doing "enterprise" stuff, i tend to avoid the heavy orm like hibernate and go for things that give me more control (spring's helper classes, say). so you can say that i am "avoiding orm".

but then recently i've been writing c code that needs to use a small database and boy, it's tedious working with sql directly. so i'm actually writing an "orm for c".

it's all about balance...

[the orm for c thing is basically two layers - a simple library that helps make sql queries a little easier to mangle and then a python library that, given some structs and a database, will auto-generate some basic boilerplate via the library. nothing fancy, but it will save a pile of tedious work.]

Re: OrmHate

#37

Post by mgkimsal »

brazzy wrote: post #11
krig wrote: post #3

"You have a relational mapping problem. 'I know', you say. 'I'll use an ORM.' You now have two problems." That just about sums up my experience with ORMs. Of course, like all things in the real world, experiences vary. However, I do think that generally, ORMs solve none of the difficult relational mapping problems and adds another layer of abstraction that complicates things like performance tuning to the point of ne…

Have you actually read TFA? Fowler's point is that yes, ORMs don't solve all of the really hard mapping problems, but save you a lot of boilerplate on the other 80-90%, and the hallmark of a good ORM is that it allows itself to be bypassed with relatively little hassle for those hard problems (like performance tuning). Also from TFA: what do you suggest using instead?

Come on - how hard is it to write

"select id, username, email, nickname, date_registered, pass_hash, first_name, last_name, middle_initial, home_phone, mobile_phone, work_phone from user where username=?" and manually do escaping whenever you want user info?

You seem to be suggesting that

user.findByUsername('joe')

is somehow more worthwhile or usable. It's certainly more noble, because an ORM doesn't solve 100% of a set of problems 100% of the time. OBVIOUSLY it's better to never use them, ever. In any circumstance.

"select id, username, email, nickname, date_registered, pass_hash, first_name, last_name, middle_initial, home_phone, mobile_phone, work_phone from user where username=?"

is really more readable because I always want to know every single piece of data, and read it every time I look at code (and update all my SQL queries every time I make a schema change) all the time. I'm finding that my monitor is often devoid of code - I have too much space on the screen just begging to be filled up with useful boilerplate code so I don't ever forget all the column names in every table.

Re: OrmHate

#38

Post by ef4 »

I think a lot of the frustration with relational databases in general comes from a misunderstanding.

People conflate "relational" with "SQL", because of the historical accident that SQL is the most popular way to query relational data. Then when SQL isn't a good fit for their problem, they think relational is not a good fit for their problem, which is almost certainly not true.

The original motivation for relational databases is to have path-independent access to data. This is a really powerful idea.

What I think we really need are better APIs around relational data access that embrace real relational semantics, instead of dumping them in favor of an object graph at the first opportunity (which throws away the path-independent access).

Re: OrmHate

#39

Post by debacle »

RyanMcGreal wrote: post #32
debacle wrote: post #15

Earlier quoted context omitted.

> Those people who best understand the inherent object-relational impedance mismatch tend to be the very people who conclude that the effort isn't worth it. You're showing a severe bias. > I have found that ORMs are the most useful for the most trivial queries. That's really what ORMs are for. Three joins, max. Any more than that and you really can't trust the ORM. It's a computer, after all, not a DBA.

In other words, ORMs are at their most useful when solving the least challenging problems. To which we must ask: why bother?

I'm going to make an argument here, and you might disagree but that's fine:

If you don't understand the purpose of an ORM, you haven't worked on a sufficiently large enough software project or don't fully understand what the definition of an ORM is.

If you need to write a report of any fashion, do not use an ORM. You can help write the report with your ORM of choice, but at some point you need to get down to the language that the database speaks because you're doing the kind of set mathematics that ORMs aren't made for.

BUT, if you need to add a user permission, and you're doing anything other than:

$user->addPermission( Permissions->get( 'CAN_EAT_CAKE' ) )

you're doing something wrong.

Re: OrmHate

#40

Post by mping »

debacle wrote: post #15
RyanMcGreal wrote: post #7

> There is a lot of truth to these charges, but such charges miss a vital piece of context. The object/relational mapping problem is hard. I suspect that context is precisely what underlies the common critiques of ORMs. Those people who best understand the inherent object-relational impedance mismatch tend to be the very people who conclude that the effort isn't worth it. In my admittedly anecdotal experience, I have…

> Those people who best understand the inherent object-relational impedance mismatch tend to be the very people who conclude that the effort isn't worth it. You're showing a severe bias. > I have found that ORMs are the most useful for the most trivial queries. That's really what ORMs are for. Three joins, max. Any more than that and you really can't trust the ORM. It's a computer, after all, not a DBA.

I strongly disagree with this. I'm consulting for a project where I cannot discuss technical decisions about database modelling; sometimes we need to query 20/30 tables or more in a tx, with very complicated mappings 5+ levels deep. If I was to write the sql for this, I'd take 10x the time and it would be wrong anyway.

Of course, this is one end of the spectrum where the ORM just enable me to shoot in the foot faster. I've also worked in the other side of the spectrum where I could use an ORM and generate exactly the sql query I wanted.

At the very least, ORMs can save you substantial time because of typesafe queries (if they are typesafe) and expressiveness (specially on join syntax).

My teacher used to say that you can solve half of your problems with an abstraction layer; I think for lots of cases an ORM does just this.

Post reply on HN