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

11–20 of 157 posts

Re: Our journey in dropping the ORM in Go

#11

Post by robertlagrant »

Some small points:

> The ORM was a natural culprit: it’s easy to see that many ORMs will make use of object introspection to build SQL statements, hydrate results, or both. Gorm’s memory footprint is extreme although sadly not uncommon. Bridge started with Python on the backend and we used Django’s ORM to interact with the database which had similar problems.

I believe these are both active record ORMs, which are not as good for various reasons (including default memory usage) as good data mappers such as SQLAlchemy and Hibernate.

As for where enums etc are "mastered" - this is still a decision to make with or without ORMs.

I think the main tricky bit of ORMs is that objects are trees and relations are graphs; this causes problems. Not so much anything about encapsulation etc.

Re: Our journey in dropping the ORM in Go

#12

Post by pionar »

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

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.

Re: Our journey in dropping the ORM in Go

#14

Post by 5e92cb50239222b »

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 you frequently have to drop two dozen functions and views (which depend on each other recursively) and then recreate them.

Re: Our journey in dropping the ORM in Go

#15

Post by topicseed »

pionar wrote: post #12
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

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..

Re: Our journey in dropping the ORM in Go

#16

Post by topicseed »

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

Re: Our journey in dropping the ORM in Go

#17

Post by njitbew »

pionar wrote: post #12
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

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.

ORMs could (and most do) provide some escape hatch, where you can write the query yourself and reuse the hydration layer, or reuse the query generator and customize the hydrator, or a combination. Or you can just bail out completely for the few performance critical queries.

Honestly, ORMs are just an abstraction. They come at a cost and they’re not a silver bullet, just like most abstractions. I believe the hate for ORMs in many cases is due to a lack of understanding/wrong expectations.

Re: Our journey in dropping the ORM in Go

#19

Post by hinkley »

There’s two reasons a problem stays unsolved. Perhaps three if you believe Jim Highsmith (we are managing paradoxes). One, it’s unsolvable, like the Halting Problem. Two, it’s an XY problem and nobody is asking the right question.

I’d been thinking recently that you could build a stupid simple ORM if you set up your SQL results to have the exact same names as your target object/struct and fed the type in as a parameter. Push these results into this box.

But that’s not the functionality that sells ORMs. It’s the object graph. Mapping relational data to graphs, ORM or not, is quite messy. Maybe that says we should be using graph databases for this sort of data instead.

Re: Our journey in dropping the ORM in Go

#20

Post by the_af »

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...

Post reply on HN