4 ms·

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

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

by pionar 5y ago

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.