6 ms·

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

rob74 5y ago
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...
- nauticacom 5y ago
  Right, but for most of that stuff I can just write a one-off query, munge it into the ORM's objects and pass that off to my view for rendering. But probably 80% of my queries are "get this object by ID" or "get these objects and some related ones by a simple condition" or maybe a slightly complex condition. In these cases an ORM works wonders and has almost zero downsides
- hello_moto 5y ago
  ORM has escape hatch so you can write SQL for the complex queries (and hopefully don't open yourself to SQL injection along the process) and still benefit from ORM for the simple to moderate case. > 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
pionar 5y ago
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.
- topicseed 5y ago
  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..
  - beachy 5y ago
    It's not just yours, it's common to most (virtually all?) ORMs, which makes these ideological arguments somewhat moot. Just use an ORM for mapping and for simple queries and hand crank the complex queries.
- njitbew 5y ago
  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.
- switchbak 5y ago
  It's also the problem of leaky abstractions. Now I need to know a lot about SQL, as well as the ORM, and in particular how the ORM maps to my conceptual model of the underlying SQL. 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.
the_af 5y ago
> 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 This is addressed in the article the title of this one refers to, "The Vietnam of Computer Science" [1]. I really recommend reading it in order to understand why the "obvious" solution is not always the best fit, but the very short summary is: due to the Object-Relational Impedance Mismatch [2], using an ORM can give you headaches and unwanted surprises. [1] http://blogs.tedneward.com/post/the-vietnam-of-computer-science/ http://blogs.tedneward.com/post/the-vietnam-of-computer-scie... [2] https://en.wikipedia.org/wiki/Object%E2%80%93relational_impedance_mismatch https://en.wikipedia.org/wiki/Object%E2%80%93relational_impe...
- makeitdouble 5y ago
  Went to most of the article, and it seemed to boil down to this kind of reflection: > But as time progresses, it’s only natural that a well-trained object-oriented developer will seek to leverage inheritance in the object system, and seek ways to do the same in the relational model. Basically, things are not perfect, and people try to blindly apply layers upon layers, thus getting deeper and deeper into a quagmire. But the proposed solution of applying no automated layer doesn’t compute. If he can restrain himself from using any ORM at all, why can’t he restrain himself from adding inheritance in ORM models or other “let’s OOP this to death” blind approach ? This feels like the “I sometimes get drunk so I’ll build a whole support structure to stop me from drinking”, and at no point someone steps in to say “just be moderate and it will be fine”
- nauticacom 5y ago
  It's no wonder this article was written in 2006. One of the problems describes DBAs! Has anyone heard of a DBA in the last decade? Most of these other problems are just... solved? Any decent language will let you override the meaning of equality between two objects, if you don't use a ton of inheritance the inheritance problem won't bite you, good libraries let you describe the schema once and either generate SQL or generate classes, etc.
  - the_af 5y ago
    Two years ago I worked at a company with a DBA team. In my current job, there are no database experts and people don't understand things like indexes. In my experience, most developers don't understand databases (of any kind). So I'd say none of the problems from that article are really solved.
henvic 5y ago
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/ 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, but at least 60%, for sure it was.
- Daishiman 5y ago
  The love comes when you're a single maintainer at a standard line-of-business app that manages a few hundred tables. 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.
- hello_moto 5y ago
  Nobody "loves" them. It's one of many tools just like generic, OOP, functional, imperative, "nullsafe" features. 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.
karmasimida 5y ago
Is writing SQL query templates too much? The only valid advantage of ORM is to prevent SQL injection, which can be solved with prepared statement.
- nauticacom 5y ago
  Okay so I write a prepared statement, send it to my database with some parameters, and get back some rows. Now what? How do I turn those rows into structs or objects or whatever that I can pass around for business logic? Maybe I write a function that takes a row and maps it to an object, I call that for every row I get back, whatever. Oh but now I'm joining a belongs-to relationship and I want that joined row represented as an object, too, so I have to write a function to convert that row and oh what if the fields have conflicting names okay I can always prefix them with the name of the table and wait sometimes I'm not querying with this related object so I have to check if the related id is included in the row and... on and on and on for every possible way I could make a different query. Great, now I've basically reinvented an ORM but it's worse because I have to manually maintain all this mapper code and it only ever accounts for the cases I've considered. If I make it fully generic, then I've really just reinvented an ORM.
  - mmcdermott 5y ago
    There are two things that get bundled together as ORMs: mapping utilities and query generation. You can have one without the other - Dapper (.NET) and JDBI (Java) are examples of mapping code without generation. The fact that you see mapping libraries without the query generation shows what's fundamentally broken about query generation. Namely, that mapping is a function of a result set. Going from a result set to an object is generally fairly straightforward. Going from an object structure to a result set (with the query merely being the declarative representation of that result set) is problematic. The hatred comes from the query generation and is, I think, sensible. The time lost attempting to trick an ORM into generate performant SQL (on top of the time taken to set it up and learn its query language on top of SQL) is a poor trade. Frankly, if it came down to it, I think I could write the mapping code manually and come out ahead over dealing with the headaches of query generation.
- 5y ago
mping 5y ago
ORMs are different from SQL generators; an eg: typesafe sql generator can be a great thing; the problem is mapping sql results (wWhich are basically rows of data) to Objects. Objects have identity, but an SQL row can be anything, even if most of the time it's a full row from a table with a primary key. As an example, if you do a query for Object o but with partial fields, and later you query for same object but full fields, are they the same object? SQL doesn't care, but in application code you need to ensure they are the "same", because objects will flow in between functions and if you eg: do o.setAge(30), you want both of the live objects to reflect that (for the same transaction). It's a hard problem with lots of compromises or rules, and I think most people are better off just with a query api.

rob74 5y ago

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

nauticacom 5y ago
Right, but for most of that stuff I can just write a one-off query, munge it into the ORM's objects and pass that off to my view for rendering. But probably 80% of my queries are "get this object by ID" or "get these objects and some related ones by a simple condition" or maybe a slightly complex condition. In these cases an ORM works wonders and has almost zero downsides
hello_moto 5y ago
ORM has escape hatch so you can write SQL for the complex queries (and hopefully don't open yourself to SQL injection along the process) and still benefit from ORM for the simple to moderate case. > 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

pionar 5y ago

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.

topicseed 5y ago
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..
- beachy 5y ago
  It's not just yours, it's common to most (virtually all?) ORMs, which makes these ideological arguments somewhat moot. Just use an ORM for mapping and for simple queries and hand crank the complex queries.
njitbew 5y ago
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.
switchbak 5y ago
It's also the problem of leaky abstractions. Now I need to know a lot about SQL, as well as the ORM, and in particular how the ORM maps to my conceptual model of the underlying SQL. 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.

the_af 5y ago

> 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 This is addressed in the article the title of this one refers to, "The Vietnam of Computer Science" [1]. I really recommend reading it in order to understand why the "obvious" solution is not always the best fit, but the very short summary is: due to the Object-Relational Impedance Mismatch [2], using an ORM can give you headaches and unwanted surprises. [1] http://blogs.tedneward.com/post/the-vietnam-of-computer-science/ http://blogs.tedneward.com/post/the-vietnam-of-computer-scie... [2] https://en.wikipedia.org/wiki/Object%E2%80%93relational_impedance_mismatch https://en.wikipedia.org/wiki/Object%E2%80%93relational_impe...

makeitdouble 5y ago
Went to most of the article, and it seemed to boil down to this kind of reflection: > But as time progresses, it’s only natural that a well-trained object-oriented developer will seek to leverage inheritance in the object system, and seek ways to do the same in the relational model. Basically, things are not perfect, and people try to blindly apply layers upon layers, thus getting deeper and deeper into a quagmire. But the proposed solution of applying no automated layer doesn’t compute. If he can restrain himself from using any ORM at all, why can’t he restrain himself from adding inheritance in ORM models or other “let’s OOP this to death” blind approach ? This feels like the “I sometimes get drunk so I’ll build a whole support structure to stop me from drinking”, and at no point someone steps in to say “just be moderate and it will be fine”
nauticacom 5y ago
It's no wonder this article was written in 2006. One of the problems describes DBAs! Has anyone heard of a DBA in the last decade? Most of these other problems are just... solved? Any decent language will let you override the meaning of equality between two objects, if you don't use a ton of inheritance the inheritance problem won't bite you, good libraries let you describe the schema once and either generate SQL or generate classes, etc.
- the_af 5y ago
  Two years ago I worked at a company with a DBA team. In my current job, there are no database experts and people don't understand things like indexes. In my experience, most developers don't understand databases (of any kind). So I'd say none of the problems from that article are really solved.

henvic 5y ago

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/ 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, but at least 60%, for sure it was.

Daishiman 5y ago
The love comes when you're a single maintainer at a standard line-of-business app that manages a few hundred tables. 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.
hello_moto 5y ago
Nobody "loves" them. It's one of many tools just like generic, OOP, functional, imperative, "nullsafe" features. 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.

karmasimida 5y ago

Is writing SQL query templates too much? The only valid advantage of ORM is to prevent SQL injection, which can be solved with prepared statement.

nauticacom 5y ago
Okay so I write a prepared statement, send it to my database with some parameters, and get back some rows. Now what? How do I turn those rows into structs or objects or whatever that I can pass around for business logic? Maybe I write a function that takes a row and maps it to an object, I call that for every row I get back, whatever. Oh but now I'm joining a belongs-to relationship and I want that joined row represented as an object, too, so I have to write a function to convert that row and oh what if the fields have conflicting names okay I can always prefix them with the name of the table and wait sometimes I'm not querying with this related object so I have to check if the related id is included in the row and... on and on and on for every possible way I could make a different query. Great, now I've basically reinvented an ORM but it's worse because I have to manually maintain all this mapper code and it only ever accounts for the cases I've considered. If I make it fully generic, then I've really just reinvented an ORM.
- mmcdermott 5y ago
  There are two things that get bundled together as ORMs: mapping utilities and query generation. You can have one without the other - Dapper (.NET) and JDBI (Java) are examples of mapping code without generation. The fact that you see mapping libraries without the query generation shows what's fundamentally broken about query generation. Namely, that mapping is a function of a result set. Going from a result set to an object is generally fairly straightforward. Going from an object structure to a result set (with the query merely being the declarative representation of that result set) is problematic. The hatred comes from the query generation and is, I think, sensible. The time lost attempting to trick an ORM into generate performant SQL (on top of the time taken to set it up and learn its query language on top of SQL) is a poor trade. Frankly, if it came down to it, I think I could write the mapping code manually and come out ahead over dealing with the headaches of query generation.
5y ago

mping 5y ago

ORMs are different from SQL generators; an eg: typesafe sql generator can be a great thing; the problem is mapping sql results (wWhich are basically rows of data) to Objects. Objects have identity, but an SQL row can be anything, even if most of the time it's a full row from a table with a primary key. As an example, if you do a query for Object o but with partial fields, and later you query for same object but full fields, are they the same object? SQL doesn't care, but in application code you need to ensure they are the "same", because objects will flow in between functions and if you eg: do o.setAge(30), you want both of the live objects to reflect that (for the same transaction). It's a hard problem with lots of compromises or rules, and I think most people are better off just with a query api.