3 ms·

Or it can mean that the engineer is tired of rewriting ORM generated queries into performant queries. Sometimes it is better to use 'explain plan' once rather

Or it can mean that the engineer is tired of rewriting ORM generated queries into performant queries. Sometimes it is better to use 'explain plan' once rather than cleaning up a generated sql filled with outer joins, table scans, and difficult to understand variable names. The ORM code in this case can look more "pristine" but can cause the app to fail in production. If you are using createNativeQuery everywhere, what is the point of an ORM?

evantbyrne 2y ago
The author presented their opinion as broadly stroked general advice and in that context it is poor. And, specifically regarding database/sql, creating a bunch of pointers to scan values into for every query you write is the definition of insanity in all but the most performance sensitive applications. We're talking microseconds (or even nanoseconds in some instances) on an operation typically measured in milliseconds.
- christophilus 2y ago
  You don’t need an ORM for that, though. I’ve used Scany in the past, and it was great. Raw, parameterized SQL that is easy to reason about and easy to scan into your structs: https://github.com/georgysavva/scany https://github.com/georgysavva/scany
  - roarcher 2y ago
    This is the sweet spot in my opinion. I haven't been in the .NET world for a few years but there's a very similar library called Dapper. Best "ORM" I ever used. https://github.com/DapperLib/Dapper https://github.com/DapperLib/Dapper
  - evantbyrne 2y ago
    These things exist on a spectrum of features but they are all mapping tables to objects at the end of the day at the bare minimum. Pedantry around what technically should count as an ORM is not super productive. The fact is that defining a schema in one place and getting a whole slew of features out of that automatically is multiplicative to productivity.
tkiolp4 2y ago
80% of the time, the queries the ORM produces are just fine. For the rest 20% left, I code them myself (I think senior engineers now how to distinguish these two scenarios). Now, what I don’t want to code myself is the transformation between rows and objects… that’s what an ORM is for.

evantbyrne 2y ago

The author presented their opinion as broadly stroked general advice and in that context it is poor. And, specifically regarding database/sql, creating a bunch of pointers to scan values into for every query you write is the definition of insanity in all but the most performance sensitive applications. We're talking microseconds (or even nanoseconds in some instances) on an operation typically measured in milliseconds.

christophilus 2y ago
You don’t need an ORM for that, though. I’ve used Scany in the past, and it was great. Raw, parameterized SQL that is easy to reason about and easy to scan into your structs: https://github.com/georgysavva/scany https://github.com/georgysavva/scany
- roarcher 2y ago
  This is the sweet spot in my opinion. I haven't been in the .NET world for a few years but there's a very similar library called Dapper. Best "ORM" I ever used. https://github.com/DapperLib/Dapper https://github.com/DapperLib/Dapper
- evantbyrne 2y ago
  These things exist on a spectrum of features but they are all mapping tables to objects at the end of the day at the bare minimum. Pedantry around what technically should count as an ORM is not super productive. The fact is that defining a schema in one place and getting a whole slew of features out of that automatically is multiplicative to productivity.

tkiolp4 2y ago

80% of the time, the queries the ORM produces are just fine. For the rest 20% left, I code them myself (I think senior engineers now how to distinguish these two scenarios). Now, what I don’t want to code myself is the transformation between rows and objects… that’s what an ORM is for.