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

61–70 of 70 posts

Re: ORMs are nice but they are the wrong abstraction

#61

Post by blagie »

PH95VuimJjqBqy wrote: post #53
feoren wrote: post #49

Earlier quoted context omitted.

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…

I kind of disagree. If you're using an ORM, the ORM is the abstraction layer which should be sprinkled throughout the code. You shouldn't wrap a layer in a layer.

If that's the right abstraction, use an ORM. If it's not, don't.

If all you have are lists of items (a todo list, a set of employee records, a set of products), an ORM is a fine abstraction. If you have or expect to do something more complex, it's probably a bad abstraction.

Re: ORMs are nice but they are the wrong abstraction

#62

Post by jasfi »

blagie wrote: post #46
jasfi wrote: post #34

Earlier quoted context omitted.

Then you'd never use an ORM, because you might require something an ORM can't handle at some point. I don't see why a coder couldn't handle a mix of both. The other factor is that ORMs tend to add features over time. Something that would require raw SQL today might be more elegantly handled with an ORM's language two years from now.

You missed the point entirely. Language like "require raw SQL today might be more elegantly handled with an ORM's language" suggests that you do not understand the elegance of SQL or the relational data model. However, you are correct. I used ORMs less and less often as I became a better SWE. They can save time on toy projects, but for those, I usually use a NoSQL or KVS directly.

I understand SQL and the relational model very well. But once I start using an ORM I want to keep using it for consistency, unless it's not the right tool for the job. Complex queries are usually the reason. Even if the ORM can technically do it, sometimes SQL is just more elegant, faster to write and I can be sure of doing it right.

Re: ORMs are nice but they are the wrong abstraction

#63

Post by PH95VuimJjqBqy »

blagie wrote: post #61
PH95VuimJjqBqy wrote: post #53

Earlier quoted context omitted.

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…

I kind of disagree. If you're using an ORM, the ORM is the abstraction layer which should be sprinkled throughout the code. You shouldn't wrap a layer in a layer. If that's the right abstraction, use an ORM. If it's not, don't. If all you have are lists of items (a todo list, a set of employee records, a set of products), an ORM is a fine abstraction. If you have or expect to do something more complex, it's probably…

> If you're using an ORM, the ORM is the abstraction layer which should be sprinkled throughout the code. You shouldn't wrap a layer in a layer.

preventing people with this belief from sprinkling ORM code all throughout the codebase is reason enough to ban the use of an ORM.

The specifics of how you retrieve data is an implementation detail. If someone wants to use an ORM have at it, but don't sprinkle it throughout the codebase, place it behind well defined functionality (behind a system dedicated to pulling data).

The fact that ORM's have their own query language should be all you need to know.

One could easily argue that you should be able to manually interact with db readers all throughout the codebase, after all, it's an abstraction.

But no one would ever actually argue that. Like such forward-only db readers, ORM's are a way to pull data, they are not the abstraction layer for pulling data for your application.

Re: ORMs are nice but they are the wrong abstraction

#64

Post by blagie »

PH95VuimJjqBqy wrote: post #63
blagie wrote: post #61

Earlier quoted context omitted.

I kind of disagree. If you're using an ORM, the ORM is the abstraction layer which should be sprinkled throughout the code. You shouldn't wrap a layer in a layer. If that's the right abstraction, use an ORM. If it's not, don't. If all you have are lists of items (a todo list, a set of employee records, a set of products), an ORM is a fine abstraction. If you have or expect to do something more complex, it's probably…

> If you're using an ORM, the ORM is the abstraction layer which should be sprinkled throughout the code. You shouldn't wrap a layer in a layer. preventing people with this belief from sprinkling ORM code all throughout the codebase is reason enough to ban the use of an ORM. The specifics of how you retrieve data is an implementation detail. If someone wants to use an ORM have at it, but don't sprinkle it throughout…

> The specifics of how you retrieve data is an implementation detail.

Correct.

> (behind a system dedicated to pulling data).

That's the textbook definition of a good ORM.

> One could easily argue that you should be able to manually interact with db readers all throughout the codebase, after all, it's an abstraction.

It depends on the abstraction they present. SQL throughout the code would be a train wreck. On the other hand, something like:

* A stored procedure to have a filtered list of gizmos...

* Mapped onto an AJAX or a function call in a data layer...

* Being called whenever one needs a filtered list....

is the way to do it. If all you have are tables of simple data, that's exactly what a good ORM would do.

Re: ORMs are nice but they are the wrong abstraction

#65

Post by mewpmewp2 »

OJFord wrote: post #57
mewpmewp2 wrote: post #48

Earlier quoted context omitted.

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

Yeah, nice example, just overall I feel like I've spent more time on edge cases/not knowing syntax top of my head with ORMs compared to if I just went with raw sql. Especially if working with different languages, each ORM handles syntax slightly differently and it messes up muscle memory.

I still automatically generate types from the database table and use helper fns when I need them to do certain type of abstraction.

And if you only need CRUD/ORM basic functions, maybe why even need a relational database. Although I would still go with relational as my first choice even if I start out with only simple CRUD, just for future's sake, so maybe not a good point.

In an ideal World there should be some sort of type parser for an sql query though.

And first class support to analyze the SQL query within the IDE (e.g. you make a syntax typo in an sql string or expose a potential sql injection vulnerability), an automatic linting or IDE tool would alert you of it, but at the same time a mechanism to generate response type if creating a parser for the compiler/build tool/IDE doesn't seem enough.

Sometimes I do end up inventing my own "ORM" with helper fns and objects, but I still feel more confident about using this one as I know that I can get exactly as flexible as I want.

Re: ORMs are nice but they are the wrong abstraction

#66

Post by blagie »

feoren wrote: post #50
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-…

> What I generally want is: > 1) Something translating SQL syntax into my native language, but maintaining SQL full semantics and expressiveness. You have just described a good ORM used well. > 2) This should allow me to be database-agnostic. Meh, you sacrifice some powerful features if you demand total database agnosticism, and how often do you actually switch databases? Being database-agnostic is a side benefit of…

> You have just described a good ORM used well.

No. I did not. ORM is an "object–relational mapping." It maps data relations onto objects.

https://en.wikipedia.org/wiki/Object%E2%80%93relational_mapp...

> how often do you actually switch databases?

Very often. Virtually all of the systems I write have at least two back-ends to maintain that flexibility. At the very least, I'd like my systems to run well locally for development but also to scale. The easiest way to do that is to e.g. support both SQLite and Postgres, but there are other ways which make sense.

In proprietary settings, I like having a BATNA. The architectural flexibility means I get better prices on hosted services and aren't liable to turning into a cash cow through lock-in. That's savings even if I'm not switching.

> If your object model is already clean and following relational principles, then mapping into that model is exactly what you want.

This is where your thinking broke. A good object model is NOT a relational model, and a good relational model is NOT an object model.

Learn the theory of both. They're both good theories, but they're different.

An ORM makes sense if you want to use an object model, but want the backing store to be an RDBMS.

> But what ORMs should be able to do (and I haven't found one that does this well) is generate SQL migration scripts for you, which you store. Those would be frozen relative to the database schema version, so all the above problems go away.

I believe that's one instantiation of what I wrote: "This may and ideally should have added functionality, for example, around managing and organizing database migrations." It's actually exactly what I was thinking.

Some ORMs do this not badly, actually. Don't let the perfect be the enemy of the good. A simple system which does 90% of the work of generating a migration (with manual verification and tweaks) is often better than a complex one which tries to do 100% of the work.

> The underlying relational model is powerful and elegant. SQL itself is not. SQL is disliked by the founders of the relational model.

Citation required.

In either case, ORMs aren't translating just syntax, but also semantics. That's where the problem lies. If you're not doing that, you're not an ORM.

> Good ORMs let you incorporate the relational model into your code.

You're confused about what an ORM is. ORMs essentially map an RDBMS onto an object model (which an OODBMS does natively). The two models are fundamentally different. It's a translation layer.

Any good database library will let me "incorporate the relational model into my code." That's not an ORM.

Re: ORMs are nice but they are the wrong abstraction

#67

Post by PH95VuimJjqBqy »

blagie wrote: post #64
PH95VuimJjqBqy wrote: post #63

Earlier quoted context omitted.

> If you're using an ORM, the ORM is the abstraction layer which should be sprinkled throughout the code. You shouldn't wrap a layer in a layer. preventing people with this belief from sprinkling ORM code all throughout the codebase is reason enough to ban the use of an ORM. The specifics of how you retrieve data is an implementation detail. If someone wants to use an ORM have at it, but don't sprinkle it throughout…

> The specifics of how you retrieve data is an implementation detail. Correct. > (behind a system dedicated to pulling data). That's the textbook definition of a good ORM. > One could easily argue that you should be able to manually interact with db readers all throughout the codebase, after all, it's an abstraction. It depends on the abstraction they present. SQL throughout the code would be a train wreck. On the ot…

right, I gathered from the first inane response that you believe anything that pulls data is an ORM.

That's never been how the acronym was defined. The reason you're now trying to define it that way is because the only other alternative is to admit you're wrong.

"what if that subsystem is pulling data from AS400?" -- still an ORM!

"what if that subsystem is pulling data from an INI file?" -- still an ORM!

"what if that subsystem is pulling data from an IOT device? via the MQTT protocol" -- still an ORM!

------

The difference between an ORM and what I'm describing is that the subsystem I'm describing actually abstracts the where and the how, an ORM _is_ an implementation detail. This is why sprinkling ORM code throughout your codebase presents a problem, it's akin to re-implementing the code to pull out of an INI repeatedly instead of putting it behind a function with a single implementation.

Now go away.

Re: ORMs are nice but they are the wrong abstraction

#68

Post by feoren »

blagie wrote: post #66
feoren wrote: post #50

Earlier quoted context omitted.

> What I generally want is: > 1) Something translating SQL syntax into my native language, but maintaining SQL full semantics and expressiveness. You have just described a good ORM used well. > 2) This should allow me to be database-agnostic. Meh, you sacrifice some powerful features if you demand total database agnosticism, and how often do you actually switch databases? Being database-agnostic is a side benefit of…

> You have just described a good ORM used well. No. I did not. ORM is an "object–relational mapping." It maps data relations onto objects. https://en.wikipedia.org/wiki/Object%E2%80%93relational_mapp... > how often do you actually switch databases? Very often. Virtually all of the systems I write have at least two back-ends to maintain that flexibility. At the very least, I'd like my systems to run well locally for d…

You're being condescending, telling me to "learn the theory". We've clearly had different experiences and work with different kinds of systems. You're automatically discounting what I say by assuming I must be a newbie because I disagree with you. No. We both have things to learn from each other and you telling me "go RTFM, newbie" is shutting down that opportunity.

> Virtually all of the systems I write have at least two back-ends to maintain that flexibility.

It sounds like that's a worthwhile tradeoff for you, but it is a tradeoff, giving up some of the unique power of each individual database in order to support both. Realize that most people don't do this.

> A good object model is NOT a relational model, and a good relational model is NOT an object model.

Maybe this is our biggest disagreement. I believe there is a model that can get the biggest benefits of both. I'm not alone in this; papers in Software Engineering, "Out of the Tar Pit", prescribes this as a possible solution to a lot of woes in software engineering:

"The classical ways to approach the difficulty of state include object oriented programming which tightly couples state together with related behaviour, and functional programming which — in its pure form — eschews state and side-effects all together ... We argue that it is possible to take useful ideas from both and that — when combined with some ideas from the relational database world - this approach offers significant potential for simplifying the construction of large-scale software systems"

https://curtclifton.net/papers/MoseleyMarks06a.pdf

I agree with them: Object Oriented Programming alone is nice for UIs but otherwise has failed to live up to its hype; Functional Programming is elegant and pure but hard to actually get anything done with; the Relational Model is simple and powerful but writing an application entirely in database procedures is a Lovecraftian Horror. So look for a model that takes the best from all three, and apply that model -- at least conceptually -- in both your database design and your application code. It is actually possible, and it's wonderful. But it will piss off the zealots on both sides.

I'm not sure what you consider "a good object model", but there is very little agreement in our industry on what exactly that looks like. If yours permits the CS 101 inheritance examples like "Dog : Animal" then I'd strongly disagree with you. Or maybe yours is the Smalltalk message-passing version: better, but still not immune to improvement. Don't assume that everyone who doesn't 100% line-toe bog standard OOP and bog standard SQL RDMSes needs to "RTFM".

>> SQL is disliked by the founders of the relational model.

> Citation required.

"SQL isn’t just user hostile, it involves some very serious departures from relational theory ... Suffice it to say that those departures are so serious that I honestly believe SQL has no real right to be called relational at all." -- Chris Date, who worked closely with EF Codd and helped spread his ideas.

https://red-gate.com/simple-talk/opinion/opinion-pieces/chri...

Re: ORMs are nice but they are the wrong abstraction

#69

Post by blagie »

feoren wrote: post #68
blagie wrote: post #66

Earlier quoted context omitted.

> You have just described a good ORM used well. No. I did not. ORM is an "object–relational mapping." It maps data relations onto objects. https://en.wikipedia.org/wiki/Object%E2%80%93relational_mapp... > how often do you actually switch databases? Very often. Virtually all of the systems I write have at least two back-ends to maintain that flexibility. At the very least, I'd like my systems to run well locally for d…

You're being condescending, telling me to "learn the theory". We've clearly had different experiences and work with different kinds of systems. You're automatically discounting what I say by assuming I must be a newbie because I disagree with you. No. We both have things to learn from each other and you telling me "go RTFM, newbie" is shutting down that opportunity. > Virtually all of the systems I write have at leas…

Citations appreciated! I will not respond in-depth to most parts, because I agree with what you're writing. But I will make one or two points. To clarify a piece of confusion:

> Maybe this is our biggest disagreement. I believe there is a model that can get the biggest benefits of both. I'm not alone in this; papers in Software Engineering, "Out of the Tar Pit", prescribes this as a possible solution to a lot of woes in software engineering:

I don't necessarily disagree, Moseley does not describe an OO model. If you showed their proposal to someone who does e.g. just Java, they would puke.

> I'm not sure what you consider "a good object model", but there is very little agreement in our industry on what exactly that looks like

A more accurate statement is that there are many models. The very first one I learned formally was the Booch method, over a quarter-century ago. My productivity fell about tenfold when I began applying it. Second one was Java. Less than tenfold. Like you, I eventually rejected OO for most things other than UX, or relatively small objects which are more-or-less little more than data types.

-----

But onto the main point:

- Models have theoretical properties which work well in isolation.

- Mixing models often destroys those properties.

- For example, I can slice code vertically or horizontally. Either works well. If I mix the two, I have no abstraction or modularity left.

- Java got rid of MI for a reason. It's not that MI is bad, but it doesn't fit into the Java OO model.

- If I add a little bit of OO to functional, I get mutation, and almost all of the benefit disappears in a poof. (note: There are systematic ways to do this which maintain benefits of both)

- Aside from theoretical properties, models are a way to communicate. You know what to expect in code.

You can design hybrid models, but you can't just mix models. Code kinda falls apart. None of the OO models map cleanly onto relational, or vice-versa. It's possible to do other models that perhaps combine aspects of both, but they're no longer OO.

An ORM is a bastardization of the two models, by trying to mesh them together. In contrast, I like Moseley Marks a lot, which is it's own model.

-----

And a footnote: I no longer find it hard to get things done with functional programming. Most of my code is pretty close to pure functional, with a few well-controlled places with state (on the front-end, with Redux). Part of that is experience on my part, but part of that is that both Python and modern JavaScript surface many of the most useful aspects of functional in ways which are linguistically nice.

-----

As a second footnote: A lot of this is based on domain. For example, numerical code works great in functional, while as you pointed out, UX maps well onto OO.

Re: ORMs are nice but they are the wrong abstraction

#70

Post by random_kris »

iccananea wrote: post #58
random_kris wrote: post #38

Earlier quoted context omitted.

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

But you have raw SQL operator and all drizzle operations does is to build you the SQL query.

Well other orms do that as well ofc. But I feel this is a low level as it can get

Post reply on HN