Our journey in dropping the ORM in Go • Hacker News Board

Re: Our journey in dropping the ORM in Go

#81

Post by dagmx » Fri, Nov 26, 2021, 10:49 PM UTC

kevmo314 wrote: post #24

As a junior dev I had no idea what an ORM was. As a mid-level dev I discovered them and wanted to use them everywhere. As a senior dev I've gone back to manually writing queries. Such is life.

As a senior dev, I use an ORM unless I have a reason not to, and I'd know why or not fairly early.

Why do I use an ORM? Because they're way more maintainable for a wider range of devs, with fewer accidental footguns, and the good ones let me do direct queries too, so there's little downside.

So I default to using an ORM like sqlalchemy , because I can hand it off to a junior dev afterwards, and they can easily keep it going without needing to be writing good SQL directly.

The other advantage is that I can abstract over multiple databases easily. So I can have an sqlite db for quick local testing, and a postgres DB for more thorough testing and another for production.

Re: Our journey in dropping the ORM in Go

#82

Post by the_af » Fri, Nov 26, 2021, 10:57 PM UTC

avgcorrection wrote: post #75

the_af wrote: post #21

Earlier quoted context omitted.

> Never understood the hate for ORMs. I need to map from my data storage to my domain model somehow, why write all that code myself This is addressed in the article the title of this one refers to, "The Vietnam of Computer Science" [1]. I really recommend reading it in order to understand why the "obvious" solution is not always the best fit, but the very short summary is: due to the Object-Relational Impedance Misma…

Maybe the original author never read Chomsky. https://chomsky.info/198210__/

Thanks for posting it. I knew Chomsky's position (that the US involvement in Vietnam was actually a war against South Vietnam, with North Vietnam as the excuse) but had never taken the time to actually read this interview in detail.

Yes, this makes the whole ORM analogy fall apart, because it's based on a misconception. But I think the analogy still works when using the popular understanding of that war as the comparison.

Re: Our journey in dropping the ORM in Go

#83

Post by [deleted] » Fri, Nov 26, 2021, 11:17 PM UTC

cageface wrote: post #70

toast0 wrote: post #52

Earlier quoted context omitted.

ORM makes the easy things easier and the hard things harder. No thanks.

So choose an ORM that lets you easily drop down to plain SQL in the rare cases where it's necessary and you get the best of both worlds.

[deleted]

Re: Our journey in dropping the ORM in Go

#84

Post by jessaustin » Fri, Nov 26, 2021, 11:24 PM UTC

dmos62 wrote: post #72

dekhn wrote: post #18

This article would have been better without the unnecessary war analogy and history lesson.

The funny thing is that it references Vietnam, while the Afghanistan exit happened just a few months ago.

The first time as tragedy, the second as farce...

As expected the linked site [0] gets the history wrong, [EDIT:] blaming JFK for getting USA into a conflict that Eisenhower had stoked over both his terms. (McGovern and Buford were shot down in early 1954.) One of the great things about assassinating your own commander-in-chief is you get to blame all your own screw-ups on him. For a while at least...

[0] http://blogs.tedneward.com/post/the-vietnam-of-computer-scie...

Re: Our journey in dropping the ORM in Go

#85

Post by exdsq » Fri, Nov 26, 2021, 11:50 PM UTC

marcus_holmes wrote: post #68

aidos wrote: post #51

Earlier quoted context omitted.

We’ve started using views and friends a lot more recently (now I’ve recovered from my PTSD from a lifetime ago when I worked in a poorly managed sql server shop). As you point out, they’re often not first class citizens. On the flip side, we’ve just moved ours to files on disk (one per object) and hacked in some tooling to autogenerate the migrations from them (we use alembic / sqlalchemy which already does a good jo…

this. Don't write your SQL into the database. Write them as scripts (starting with "drop XYX", then "create XYZ", check them into git, and treat them as code. Migrations are for schema changes. Views and functions are not schema.

Wait. People don't do this?

Re: Our journey in dropping the ORM in Go

#86

Post by mleonhard » Sat, Nov 27, 2021, 12:02 AM UTC

    // updates the whole table, ignoring conditions
    db.Model().Where().Updates()
    // updates the rows matching conditions
    db.Model().Updates().Where()

This is a massive footgun in Gorm. Don't use tools that help you make catastrophic errors.

Re: Our journey in dropping the ORM in Go

#87

Post by eric4smith » Sat, Nov 27, 2021, 12:07 AM UTC

Heh.

Recently I had to stand up a quick elixir project and decided to write all queries by hand and not use Ecto.

It was extremely enjoyable writing every query from the start. Just thinking carefully about what columns I needed, and crafting the best joins and where clauses made efficiency baked in from the beginning.

If one is not careful and just be lazy with an ORM you get back all columns all the time - and this is the biggest sin of an ORM. Not to mention sub-optimal where clauses that kill performance.

And the next positive side effect was the amazing speed of the database interactions in the app.

It’s not something I’d do all the time since sometimes you do need the discipline of Ecto, but I say we should write more sql by hand instead of less.

Re: Our journey in dropping the ORM in Go

#88

Post by domlebo70 » Sat, Nov 27, 2021, 12:12 AM UTC

marcus_holmes wrote: post #3

So frustrating. You got like 80% of the way there, and then went "nope, too much work" and diverted to add more complexity. The answer is to write the SQL yourself, and the scan methods yourself. Code generation is better than ORM, but still a wrapper, still adds complexity, and still brings problems. Yes it's a pain in the arse to write all that boilerplate in one go (pun intended). But if you'd started without an O…

What is the idea behind using views? I have never used them

Re: Our journey in dropping the ORM in Go

#89

Post by [deleted] » Sat, Nov 27, 2021, 12:15 AM UTC

pixelgeek wrote: post #28

dominotw wrote: post #7

i thought we'd all agreed 15 yrs ago to not use vietnam analogy to discuss orms.

What sort of ghoul compares a programming issue with something like the conflict in Vietnam? When he started writing about 15 million people dying you think that would have made him stop and rethink the metaphor.

[deleted]

Re: Our journey in dropping the ORM in Go

#90

Post by ufo » Sat, Nov 27, 2021, 12:21 AM UTC

dominotw wrote: post #7

i thought we'd all agreed 15 yrs ago to not use vietnam analogy to discuss orms.

The saddest part of the analogy is how US-centric it is. "Vietnam" is a boondoggle to exit from, not a home that's suffering through a bloody conflict.