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

ORMs are nice but they are the wrong abstraction

workdad.dev

Post reply on HN
Print view View original

51–60 of 70 posts

Re: ORMs are nice but they are the wrong abstraction

#51

Post by 1st1 »

Taikonerd wrote: post #32

The DB/ORM mismatch is worse than it has to be, because SQL queries always return flat rows. But in code, we don't usually want rows; we want objects linked to other objects: "get me the Account objects and their associated Wishlists." If you use a query language that knows that we want objects linked to other objects, you can still have an ORM, but it doesn't have to do as much heavy lifting. The query can already s…

Yeah, that's the exact goal of EdgeDB -- unlock proper hierarchical data retrieval and mutation as well as making composition possible both at the schema and query layers. Most other perks EdgeDB has are the direct result of that.

Re: ORMs are nice but they are the wrong abstraction

#52

Post by kaba0 »

blagie wrote: post #17
jasfi wrote: post #6

ORMs are useful when what you want to do matches their expressiveness. For example when I just want to get a record by its primary key. They have their limits, many times when doing complex reports. For that, most ORMs provide a raw SQL function. So just use the right tool for the job. Stored procedures for business logic can be great for performance when they replace queries/mutations called thousands+ times.

ORMs are nice for "Hello World," and hit a brick wall later. I don't mind them for simple systems, but for more complex systems which need SQL, don't use an ORM. Mixing ORMs with raw SQL generally mixes and breaks layers of abstraction. This leads to a situation where the overall system is more complex than having a sane relational abstraction. For example, ORMs do a lot implicitly. A code change at the language leve…

If you don’t know SQL, you shouldn’t touch ORM either, no one ever said that you can.

Also, it’s pretty reductionist to say that it is only good for simple systems, when in fact, huge services are running it at almost all companies.

Re: ORMs are nice but they are the wrong abstraction

#53

Post by PH95VuimJjqBqy »

feoren wrote: post #49
PH95VuimJjqBqy wrote: post #42

Earlier quoted context omitted.

> Most people never learn databases, and most people who do are idiots working on enterprise three-tier architectures Tell me how you really feel :) My biggest problem with ORM's is that it causes people to sprinkle the ORM code throughout their codebase but they'd never do that with SQL, they'd want to try and sequester it to a system whose responsibility is the retrieving and updating of data. It puts people into a…

That's like saying: my problem with Functions is that people sprinkle them throughout their codebase, instead of having one single place where all their Functions are defined. For most applications, "Retrieving and updating data" is the entire point , or at least a deeply fundamental part of how they work. It shouldn't scare you that such a core function -- the entire reason your application exists -- is "sprinkled a…

putting repeated data requests behind a function is what I'm suggesting...

sprinkling your ORM code all throughout your codebase is the equivalent of NOT using functions but instead copy/pasting the implementation everywhere it's needed.

Most ORM's recognize this is a problem, which is why they often try to bake in some sort of solution for re-use, only it's always done badly. They'll generally attach it to the model and it will turn into some sort of unobvious behavior or they'll attempt to be able to attach SQL fragments by name. What it ends up doing is effectively spreading an SQL query over several files. Often by convention so there's no real way to know if part of the query is going to be in file X without just checking or knowing ahead of time.

Re: ORMs are nice but they are the wrong abstraction

#54

Post by mike_hearn »

pjc50 wrote: post #29
mike_hearn wrote: post #26

The most interesting/fresh approach I've seen to this problem is Permazen. https://github.com/permazen/permazen/ It starts by asking what the most natural way is to integrate persistence with a programming language (Java in this case, but the concepts are generic), and then goes ahead and implements the features of an RDBMS as an in-process library that can be given different storage backends as long as they implemen…

.. but you can't really do queries on a K/V store?

Sure you can. In Permazen they're expressed as set operations over collections of objects, so you use map, filter, fold etc as you would if programming functionally. Indexes are also exposed as collections.

Reads and writes on those objects are then mapped to K/V operations.

Re: ORMs are nice but they are the wrong abstraction

#56

Post by selfportrait »

hardware2win wrote: post #28

Too much ORM hate in this thread They are really useful for like 90% of the work The rest can be made with raw sql Combine strengths of those two powerful tools, dont be religious

This here. If you follow Prisma ORM on GitHub, some of the pain you’ll see is missing features like “whereRaw”, but really most of the pain is forcing you to use raw SQL. And even then, Prisma is extensible, so build your own solutions on top of it. Like Zenstack which creates auth/role permissions on the Prisma schema.

Way too much ORM hate here.

Re: ORMs are nice but they are the wrong abstraction

#57

Post by OJFord »

mewpmewp2 wrote: post #48
OJFord wrote: post #41

Earlier quoted context omitted.

To be fair your 'only for some basic CRUD queries' is just a rephrasing of GP's 'they are for OLTP'.

But one issue with ORMs is also that they can bait you to try more complex queries, where eventually you might run into one slight edge case that you spend huge amount of time finding a solution for because reverting to raw SQL will not feel elegant at that point - and feels like you've failed in some way. So you might run into these edge cases and then also you might have terrible joins without really knowing. Also…

To be clear, ORMs are not my preference either: https://stackoverflow.com/questions/65596920/use-django-subq...

Re: ORMs are nice but they are the wrong abstraction

#58

Post by iccananea »

random_kris wrote: post #38
blagie wrote: post #16

The basic problem is that: 1) Relational databases are the best abstraction we've found for storing data. Despite years of attempts (OODB, XML databases, various nosql stores, etc.), we have not been able to improve on it. postgresql, by adding native JSON support, became a better mongo than mongo virtually overnight. 2) Most people never learn databases, and most people who do are idiots working on enterprise three-…

https://orm.drizzle.team/ Basically this ?

Drizzle does exactly what I described in the article: it re-implements SQL in the target language (in this case TypeScript).

Re: ORMs are nice but they are the wrong abstraction

#59

Post by iccananea »

ranedk wrote: post #37

I know tons of Java and Go Dev's who don't like ORMs and for a good reason. But no Django developer ever cribs about ORMs.

Ironically I started drafting this article in 2021, when I had to deal with a Django codebase littered with nested N+1 queries due to using the ORM in the most pythonic way.

Re: ORMs are nice but they are the wrong abstraction

#60

Post by iccananea »

gmac wrote: post #14

ORMs suck, but raw SQL embedded in your code sucks too. This might be good time to plug my Postgres/TypeScript non-ORM: https://jawj.github.io/zapatos/ . I should say I also like what I've seen of https://kysely.dev/ and https://pgtyped.dev/ .

Agreed, but tools like https://sqlc.dev, which I mention in the article, are a good trade-off that allows you to have verified, testable, SQL in your code.
Post reply on HN