41–50 of 157 posts
i thought we'd all agreed 15 yrs ago to not use vietnam analogy to discuss orms.
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
Because relational databases are very good at (surprise!) relations. So in SQL you can query data from several joined tables, query only certain columns, aggregate columns etc. etc. And all of these things are made needlessly complicated by using ORM. Even with the best ORM, you still have to learn an arcane new syntax for stuff you could write in 30 seconds when using SQL...
> So in SQL you can query data from several joined tables
Can do that in your ORM too.
> query only certain columns
So far no issue with ORM
I feel like the biggest problem with an ORM is how people try and use them. It’s like an all or nothing approach. You hit a wall where using an ORM for that sucks and so now using an ORM for everything sucks. I never would have thought of using an ORM in golang, it doesn’t seem like that kind of language. Even an ORM in python is debatable.
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…
Most apps don't need to be performant. Most business logic is object-centric and relation-centric. Leveraging the best features of highly-integrated frameworks like Django and Rails mean that the framework has to understand and talk to objects, not database rows.
I have maintained several Django projects with a couple hundred tables by myself or another team member. I cannot imagine maintaining such a gigantic heap of equivalent SQL for trivial business logic.
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.
The cognitive load (with some more than others) of this can be extreme. I'm thinking of Hibernate I'm particular.
I think there's a good underlying drive for this: type safe, composable, declarative language-centric queries. Especially helpful with bulk data management. I think if SQL was a more natural mapping to this model, it wouldn't be so bad, but SQL was not created for programmatic interaction (it was created to be hand written), and can be challenging to create abstractions around.
These days I'll lean on simple ORM-light tools, but quickly prefer an escape hatch when things get even a little complex. Mapping the output is something that I'm happy to delegate to a framework though.
Some tools can even provide compile time type checking of your queries, I think that's getting somewhere more interesting.
i thought we'd all agreed 15 yrs ago to not use vietnam analogy to discuss orms.
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…
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...
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…
Long list of tools with usefulness.
I find people who tend to develop extreme on either end aren't that pragmatic.
I read your blog and I don't see any problems caused by ORM. Your product data model should fit in ORM (I get it, you're just using it as a simple example). The blog only mentioned "I used ORM in the past and had bad experience" without explaining the problems.
> 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
That seems to be the problem: your previous workplace, not the ORM itself.
What feels wrong to me in this post is the lack of nuance on how they used their ORM. For instance the whole part on how the ORM generated queries they wish were done in a different manner: why didn’t they bother writing either lower level code or just raw SQL to get their data as they wished ?
It looks to me they could have kept their ORM for the 80% cases it works great, and hand tune the 20% that could be problematic. Just like any other optimization problem.
There would be still the performance part where some overhead would still be there, but it’s usually not an issue if the ORM option was on the table in the first place.
Mature ORMs (that still often suck) are built by literally thousands of open-source contributors.