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

To ORM or Not to ORM

eli.thegreenplace.net

Post reply on HN
Print view View original

51–60 of 300 posts

Re: To ORM or Not to ORM

#51

Post by gen220 »

bkq wrote: post #35

Personally I think an active record style ORM for Go like gorm is a poor fit for a language that doesn't come across as inherently OOP. Going through some of the documentation for gorm, it seems to rely heavily on method chaining which for Go seems wrong considering how errors are handled in that language. In my opinion, an ORM should be as idiomatic to the language as possible. I've used sqlx[1] before, and it feels…

For my 2¢, We use squirrel at work (I haven't touched it myself though). People here seem to like it.

It's not an ORM per se, but it seems to occupy the sweet spot you're describing. It takes away some of the more tedious parts of using SQL, but allows you to still reason about what's happening under the hood without committing tons of documentation to memory.

Suits the language quite well, I think!

Re: To ORM or Not to ORM

#52

Post by hugi »

strictfp wrote: post #47
hugi wrote: post #13

I believe that People who hate ORMs haven't used a good ORM, so what they really hate is the tool, not the concept. I like using my ORM of choice when it's appropriate, I like just using SQL statements when it's appropriate. Choose the tool appropriate for the task.

I've used many ORMs. I don't hate them, but I think their net utility is negative. While you initially might think that interfacing with the db is going to be very tedious and labor intensive, it usually turns out to not be that bad. Battling the ORM to make it do what you want can on the other hand be very tedious. When you have the SQL in the code it's much more obvious what the performance profile and potential co…

I tend to disagree. To me a good ORM totally (ok, not totally, but as totally as possible) abstracts the database away from your code. That's it's purpose. You just want to work with data. You want to fetch data, persist data and delete data - you don't really want to care about how that's done. That's where a good ORM can really help you out.

However, if the ORM gets in your way, either because of API complexity, performance issues or other reasons, and you start to "battle" it as you said, you immediately move out of that context and start thinking in a more data oriented context. That's where SQL comes in.

As I said before, I think it's a question of using the appropriate tool. I've written hundreds of applications using multiple different ORMs and just plain SQL—and I'll tell you I'll pick a good ORM over raw SQL for basic CRUD operations every time.

However, I'll give you that I'll pick plain SQL over a bad ORM any day.

Re: To ORM or Not to ORM

#53

Post by topspin »

toast0 wrote: post #4
ordinaryperson wrote: post #3

Sample size one 1 but ORM drives me crazy. Why can't we just use SQL? How does it save time when I have to learn the ORM language, which probably has a lot less support and users? The OP here says it "reduces boilerplate" -- rarely have I created an application and thought its biggest problem was too much boilerplate. But everyone at work loves them so I must be wrong somehow.

All the time allegedly saved is also more than compensated for when the ORM makes bad queries that are roughly impossible to fix.

Frequently the easiest path to perform a complex query with an ORM results in N+1 performance disasters. The inevitable retort is something like "but the ORM has better ways to do that." Of course it does; ORM implementers aren't incompetent. The key word is "easiest," meaning the ORM user doesn't have to spend time learning anything beyond simply chaining method calls. In production such work goes haywire when resolving some related entity causes tens of millions of round trips.

Without an ORM the easiest path is to write a single join, giving the database optimizer a fair shot at correctly optimizing the query, including over time as the database evolves. Again, yes an ORM can encapsulate the equivalent query. Guess what; for every time these ORM capabilities are actually utilized there are probably hundreds of expediently written N+1 queries because the programmer either didn't know better or was indifferent.

To a pragmatic mind this is the inevitable outcome when a tool makes the inefficient solution the easiest thing to do.

Re: To ORM or Not to ORM

#54

Post by vinceguidry »

davidcuddeback wrote: post #36
localhostdotdev wrote: post #25

rails g model Post published_at:datetime title content:text rails g model Comment post:references author published_at:datetime content:text rails g model Tag name rails g model PostTag post:references tag:references class Post from there it's just regular rails: Tag.find_by(name: "something").posts Post.joins(:tags).where(tags: { name: "something" }) Tag.create(name: "something") Post.create(...) Tag.first.posts made…

You forgot to add an index on tags.name and null constraints on the rest of the columns. > from there it's just regular rails That's the problem. Examples like this focus on the first few minutes of development. Not the subsequent years of maintenance.

> Not the subsequent years of maintenance.

You're gonna have to pry the Rails from my cold dead fingers if you want me to maintain a web app's database abstraction layer long-term. No other tool works half as well as ActiveRecord. You could maybe convince me to try out https://rom-rb.org/ but only on a brand new project and only if Rails isn't appropriate.

If it's a project that wasn't built with Rails, I'm going to want https://github.com/jeremyevans/sequel if ActiveRecord is too much trouble to introduce.

Re: To ORM or Not to ORM

#56

Post by tlrobinson »

henning wrote: post #20

I wish people did not think the choice was solely between "write raw SQL with raw strings" and "try to pretend the database is object-oriented when it is not." The third approach is to safely wrap the database and its columns with code in a way that is composable. In Python, SQLAlchemy has an ORM, but it is optional, and you can just work with tables and columns if you want.

At Metabase I think we've found a nice middle ground with our "Toucan" library for Clojure: https://github.com/metabase/toucan

Re: To ORM or Not to ORM

#57

Post by zzzeek »

lukifer wrote: post #30

As true now as it was 12 years ago: ORMs are the Vietnam of computer science. http://blogs.tedneward.com/post/the-vietnam-of-computer-scie... (tl;dr: there is an impedance mismatch / leaky abstraction between relational data and OOP for all but the most trivial use cases, guaranteeing that whatever problems an ORM might solve will be traded for new ORM problems instead)

I wonder how people of Vietnamese heritage would feel that you are characterizing their country as synonymous with war and disaster? IIUC Vietnam had been a relatively peaceful country for almost 50 years.

Not coincidentally ORMs have been doing great since that silly article was written so many years ago.

Re: To ORM or Not to ORM

#58

Post by chusk3 »

rspeele wrote: post #49

I put a ton of work into an ORM that statically typed SQL a couple years ago. I always thought this would be a cool way to go. https://github.com/rspeele/Rezoom.SQL/ But I never got to use it at work, and thus lost interest. The biggest thing missing with it was that you lost type safety if you had to dynamically build a query. These days its main problem is lack of compatibility with .NET Core, which somebody else w…

For my money your type provider was the single coolest one I've seen before. The ahead of time query execution and planning is a killer feature, and for us the only gaps were either process related, meaning we did not have a good out-of-band migration pipeline, or some constructs that were not understood by your type provider.

Re: To ORM or Not to ORM

#59

Post by megous »

y4mi wrote: post #15
ordinaryperson wrote: post #3

Sample size one 1 but ORM drives me crazy. Why can't we just use SQL? How does it save time when I have to learn the ORM language, which probably has a lot less support and users? The OP here says it "reduces boilerplate" -- rarely have I created an application and thought its biggest problem was too much boilerplate. But everyone at work loves them so I must be wrong somehow.

I love orms. They make a simple crud operation so easy, you don't even have to think about them. Every remotely competent developer will however tell you that there are always cases where the orm is a bad fit. And that's exactly why basically all orms let you write your own queries. There is really no reason not to use an orm. Just don't ever frown on people doing anything more advanced than a middle join without it.

You don't need ORM for simple CRUD operations. All you need is a function you can pass a table name and a map of column names/values you want to insert/update.

Re: To ORM or Not to ORM

#60

Post by sdegutis »

henning wrote: post #20

I wish people did not think the choice was solely between "write raw SQL with raw strings" and "try to pretend the database is object-oriented when it is not." The third approach is to safely wrap the database and its columns with code in a way that is composable. In Python, SQLAlchemy has an ORM, but it is optional, and you can just work with tables and columns if you want.

There are so many incompatible needs for databases that most DB wrappers of any kind rarely make sense except when prototyping. And database wrapper authors have a tendency to cater to lowest common denominator of features so that they can treat all databases the same, which is going even further in the wrong direction. Choosing a database requires learning what your requirements are, learning what the candidates are, and when you pick one, learning how to use it correctly. People and companies rarely seem to do all of these steps.
Post reply on HN