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

21–30 of 157 posts

Re: Our journey in dropping the ORM in Go

#21

Post by the_af »

nauticacom wrote: post #5

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

> 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 Mismatch [2], using an ORM can give you headaches and unwanted surprises.

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

[2] https://en.wikipedia.org/wiki/Object%E2%80%93relational_impe...

Re: Our journey in dropping the ORM in Go

#22

Post by 2StepsOutOfLine »

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'm shocked more people arent talking about SQLBoiler in threads like these. It solves this exact problemset. You write the SQL schema and it generates all the scan and helper functions for you. We've had a great experience with it at work after running into similar woes as OP with ORM's.

https://github.com/volatiletech/sqlboiler

Re: Our journey in dropping the ORM in Go

#23

Post by henvic »

nauticacom wrote: post #5

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

I never understood the love for them.

I recently posted this about my experience in migrating to PostgreSQL without anything of the sort of ORM... https://henvic.dev/posts/go-postgres/

We achieved a really great result doing so. In comparison, at my previous workplace, I was forced to use ORM, and everything was slower, awful, and hard to maintain for no benefit whatsoever. I'm not saying that it's 100% fault of ORMs, but at least 60%, for sure it was.

Re: Our journey in dropping the ORM in Go

#25

Post by cjdell »

topicseed wrote: post #16
cjdell wrote: post #4

In NodeJS Prisma is really good for just building statically typed CRUD-like queries. It gives you result types inferred from the schema so you're less likely to make mistakes. Would still use real SQL for serious stuff, but in my experience most queries are CRUD anyway so I don't see lightweight ORMs as a problem as long as they're not doing magic caching in the background and lazy fetching. Let me decide how I want…

Using MikroORM in NodeJS and works wonders. Has the "raw" option for queries I want to handle myself, or even the "knex" builder for something in between

Hmm... Looks like a "active record" pattern (like Hibernate). This is exactly what I don't want. Essentially I only use ORMs as query builders. No magic behinds the scenes.

Re: Our journey in dropping the ORM in Go

#26

Post by taeric »

rjsw wrote: post #13
dominotw wrote: post #7

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

The last reference to Vietnam that I saw in the MSM was that it had done a good job of handling COVID-19. Maybe the article is describing a good use of an ORM.

I think that ship eventually left harbor. :( Scanning their charts, July and August spiked heavy.

Re: Our journey in dropping the ORM in Go

#27

Post by Ciantic »

The hate should be directed at SQL builder part of most ORMs. Which gets complicated pretty quickly, and it's like learning a new language when SQL works usually much better.

If you write your SQL, and some tool, like code generation, then maps it to object, you are golden. It's the part you'd have to write anyway. However if the code generation goes bust (like gets abandoned like most hobby mappers), you should make sure you can take the code and continue like you never used the generator in the first place.

It looks like the authors suggestion SQLC is pretty close to that. It seems to generate a lot of code though, so it might be an issue if you don't want to maintain SQLC, test it out in here: https://play.sqlc.dev/

Re: Our journey in dropping the ORM in Go

#28

Post by pixelgeek »

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.

Re: Our journey in dropping the ORM in Go

#29

Post by beachy »

topicseed wrote: post #15
pionar wrote: post #12

Earlier quoted context omitted.

The hate isn't in the mapping. It's perfectly reasonable to abstract away mapping of relational data to objects. It's the translation of objects to SQL queries that's the problem. ORMs typically output inefficient and mostly obfuscated SQL, when a human can do a better job of hand-writing the SQL, knowing the data usage patterns needed.

Speaking for Typescript and Mikro-ORM. I use the ORM extensively for regular operations and queries, but usually for searches with more complex queries, I do it by hand (get PKs), and then load the entities by PK (I could skip that but it's to let the ORM handle the mapping). ORMs generally have a "raw" escape route where you can just do it yourself? Or maybe it's just the one I use..

It's not just yours, it's common to most (virtually all?) ORMs, which makes these ideological arguments somewhat moot.

Just use an ORM for mapping and for simple queries and hand crank the complex queries.

Post reply on HN