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

Our journey in dropping the ORM in Go

alanilling.medium.com

Post reply on HN
Print view View original

51–60 of 157 posts

Re: Our journey in dropping the ORM in Go

#51

Post by aidos »

5e92cb50239222b wrote: post #14
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…

> I write a view for each access method (so I can change the schema without worrying about changing every access method), and a function for each update/insert/delete (for the same reasons). God how I hate supporting such architecture. It loses edit history unless you're very careful (which many developers are not) and do absolutely every piece of DDL in a versioned migration, and makes DDL extremely painful because…

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 job here).

It’s kinda the promised land. Edit code on disk, commit and review as usual.

Re: Our journey in dropping the ORM in Go

#52

Post by toast0 »

karmasimida wrote: post #36
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.

ORM is that one layer that fails to abstract anything substantial yet whose existence is intrusive enough to annoy people. The worst example of leaky abstraction.

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

Re: Our journey in dropping the ORM in Go

#55

Post by dominotw »

the_af wrote: post #20
dominotw wrote: post #7

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

The article this title refers to [1] is very insightful, and I don't think it was ever improved by something better (analogy-wise, or more descriptive). [1] http://blogs.tedneward.com/post/the-vietnam-of-computer-scie...

thats the article i was referring to.

i remember a lot of consternation about that analogy

followp

http://blogs.tedneward.com/post/thoughts-on-vietnam-commenta...

Re: Our journey in dropping the ORM in Go

#56

Post by aidos »

toast0 wrote: post #52
karmasimida wrote: post #36

Earlier quoted context omitted.

ORM is that one layer that fails to abstract anything substantial yet whose existence is intrusive enough to annoy people. The worst example of leaky abstraction.

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

Can you provide some examples? I use sqlalchemy, and the amount of work that it does for me when it comes to handling mutating data is pretty remarkable.

Re: Our journey in dropping the ORM in Go

#57

Post by hn_throwaway_99 »

meitham wrote: post #47
hn_throwaway_99 wrote: post #39

Earlier quoted context omitted.

I've been a huge fan of Slonik, https://github.com/gajus/slonik , which makes it easy and safe to write direct SQL queries. The author of Slonik had a good article about the downsides of query builders, previously discussed on HN, that I totally agree with: https://gajus.medium.com/stop-using-knex-js-and-earn-30-bf41...

On the contrary, I hate dealing with the various escaping characters for SQL, and to me SQLAlchemy expression is a life-saver. It gives me back a textual sql expression as a string and I can choose exactly how to run it. I do avoid the ORM part as I like to be in total control of the transaction, and I am often in the python async world, where ORM don't play nicely.

> I hate dealing with the various escaping characters for SQL

I don't understand that bit, with something like Slonik you don't use escape characters, it does it transparently for you by taking advantage of JavaScript's string template literals.

Re: Our journey in dropping the ORM in Go

#58

Post by irq-1 »

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…

Putting all SQL into the database gets you two huge advantages: First, all relations and dependencies are visible for DDL changes, and what the code uses is easy to see without looking through the code. Second, a test database can use (near) live data with the new DDL and new code, making testing much better especially for non-development staff who can spot issues based on the data or UX.

Re: Our journey in dropping the ORM in Go

#59

Post by the_af »

dominotw wrote: post #55
the_af wrote: post #20

Earlier quoted context omitted.

The article this title refers to [1] is very insightful, and I don't think it was ever improved by something better (analogy-wise, or more descriptive). [1] http://blogs.tedneward.com/post/the-vietnam-of-computer-scie...

thats the article i was referring to. i remember a lot of consternation about that analogy followp http://blogs.tedneward.com/post/thoughts-on-vietnam-commenta...

Well, in my mind Ted Neward's thoughts in that followup explain why it's still an illustrative analogy.

Re: Our journey in dropping the ORM in Go

#60

Post by toast0 »

aidos wrote: post #56
toast0 wrote: post #52

Earlier quoted context omitted.

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

Can you provide some examples? I use sqlalchemy, and the amount of work that it does for me when it comes to handling mutating data is pretty remarkable.

No real specifics, but I usually run into ORM in the context of I'm the person on the team with experience running MySQL and someone has a slow query. When they're hand built queries, I can usually provide a query or sequence of queries that provides the same data without knocking the server over and it gets put into production within the same day. When they're ORM, it takes days to find the query, and then more days to bend my query sequence to fit the ORM.

Sometimes you can add indexes to fix things, but sometimes you really just need to do a simple query followed by a large number of single row queries unioned together, but that doesn't seem to be a feature of the ORMs I've been adjacent to.

Post reply on HN