7 ms·

My basic complaint about ORM is that it is such a massively leaky abstraction. That the (sometimes, but not always-made) claim that it 'abstracts away the sql'

by lcuff 4y ago

My basic complaint about ORM is that it is such a massively leaky abstraction. That the (sometimes, but not always-made) claim that it 'abstracts away the sql' is just plain false. An understanding of SQL is typically necessary. Many ORMS are introduced by saying 'this expression translates to that sql'. Oops, no abstraction there. I like this sketch of objection because it's in some respects just friendler sql syntax.

nextos 4y ago
Yeah, even SQL is leaky as two equivalent queries may have dramatically different execution plans. Actually, knowing how to write efficient SQL is very well rewarded by the market. So adding another layer on top of it, an ORM, is IMHO not a good idea.
isoprophlex 4y ago
Yes, I totally agree. Something isn't working? Oops, now you still gotta look at the SQL! Also... I've seen several anti-pattern usages where someone would query a list of IDs, and then in a loop with an accumulator fetch data from another table, one ID at a time. If you don't grok joins, and someone tells you "yeah whatever don't bother learning SQL, we have an ORM", this happens. An ORM is an anti-tool.
wvenable 4y ago
I hate the complaint that everything is a "leaky abstraction". Can't we just just accept a tool that augments and improves something without caring that it's not a complete and perfect abstraction over another technology? I use an ORM every day and I also use SQL every day. The ORM is such an improvement for what it does that of course I would use it. But I'm not restricted to using it. In fact, most ORMs encourage mixing SQL with their API; that's not a leaking abstraction -- it's bringing the fire hose.
ebiester 4y ago
Is that implementation or is that a base problem? I agree - I would much rather write SQL. But like others have said in this thread, I hate writing custom code to translate anything but the simplest queries into what I actually need. I also hate trying to combine slightly different queries with custom string manipulation that turns into 750 lines of code before you know it. Most ORMs handle that use case very well.
kaba0 4y ago
> claim that it 'abstracts away the sql‘ I have never ever met anyone who genuinely used ORM claim that in any form of shape. The only ever place where I’ve seen it is threads about “how bad ORMs are”, so it is only a strawmen. ORMs are first and foremost a tool for OLTP-based workflows, helping mapping between objects and db rows, especially for insertions. They are also very great for CRUD operations on tables. They were never meant to abstract away the SQL model, that is one necessarily has to know the underlying tables, and often write queries with manual joins, etc (many ORMs allow custom queries in a cross-DB way). But even in these cases mapping the result is very convenient with an ORM.

by lcuff 4y ago

nextos 4y ago

Yeah, even SQL is leaky as two equivalent queries may have dramatically different execution plans. Actually, knowing how to write efficient SQL is very well rewarded by the market. So adding another layer on top of it, an ORM, is IMHO not a good idea.

isoprophlex 4y ago

Yes, I totally agree. Something isn't working? Oops, now you still gotta look at the SQL! Also... I've seen several anti-pattern usages where someone would query a list of IDs, and then in a loop with an accumulator fetch data from another table, one ID at a time. If you don't grok joins, and someone tells you "yeah whatever don't bother learning SQL, we have an ORM", this happens. An ORM is an anti-tool.

wvenable 4y ago

I hate the complaint that everything is a "leaky abstraction". Can't we just just accept a tool that augments and improves something without caring that it's not a complete and perfect abstraction over another technology? I use an ORM every day and I also use SQL every day. The ORM is such an improvement for what it does that of course I would use it. But I'm not restricted to using it. In fact, most ORMs encourage mixing SQL with their API; that's not a leaking abstraction -- it's bringing the fire hose.

ebiester 4y ago

Is that implementation or is that a base problem? I agree - I would much rather write SQL. But like others have said in this thread, I hate writing custom code to translate anything but the simplest queries into what I actually need. I also hate trying to combine slightly different queries with custom string manipulation that turns into 750 lines of code before you know it. Most ORMs handle that use case very well.

kaba0 4y ago

> claim that it 'abstracts away the sql‘ I have never ever met anyone who genuinely used ORM claim that in any form of shape. The only ever place where I’ve seen it is threads about “how bad ORMs are”, so it is only a strawmen. ORMs are first and foremost a tool for OLTP-based workflows, helping mapping between objects and db rows, especially for insertions. They are also very great for CRUD operations on tables. They were never meant to abstract away the SQL model, that is one necessarily has to know the underlying tables, and often write queries with manual joins, etc (many ORMs allow custom queries in a cross-DB way). But even in these cases mapping the result is very convenient with an ORM.