+ {{ page.description }} +
++ It's no secret that + I'm no fan of ORMs. Most people, on the other hand, find them indispensable. As one reader + commented: +
++- {{ page.description }} -
-- It's no secret that I'm no fan of ORMs. Most people, on the other hand, find them indispensable. As one reader commented: -
---- "I can work with raw SQL ofcourse... but the mapping... oh the mapping..." -
- -- This seems to capture something essential. When I discuss ORMs, the most common argument in favour seems to revolve around the amount of boilerplate code required to communicate with a relational database. And indeed, it's significant. -
-- As I've argued, however, I'm not convinced that ORMs solve that problem. -
-- But now that LLMs write code, does it even matter? -
-- In addition to my individual reservations, it strikes me that ORMs come with many issues related to query efficiency. The vibe I'm getting from ORM experts is that if you really know a particular ORM, you can fine-tune the queries it makes. There are, however, various pitfalls to avoid: Anti-patterns to eschew, idioms to follow, particular APIs to keep clear of, certain parameter values to explicitly pass, etc. -
-- Which strikes me as ironic, because wasn't the whole promise of ORMs that you could read from and write to a relational database without getting bogged down in the details of SQL? -
-- So instead of fiddling with a temperamental and implicit ORM API, why not write fine-tuned parametrized SQL queries? Or rather, ask an LLM to do that for you, as well as all the boilerplate code. -
-- You should, of course, remind it to avoid SQL injection vulnerabilities. + "I can work with raw SQL ofcourse... but the mapping... oh the mapping..."
+ +
+ This seems to capture something essential. When I discuss + ORMs, the most common argument in favour seems to revolve around the amount of + boilerplate code required to communicate with a relational database. And + indeed, it's significant. +
++ As I've argued, however, I'm + not convinced that ORMs solve that problem. +
++ But now that + LLMs write + code, does it even matter? +
++ In addition to my individual reservations, it strikes me that ORMs come with + many issues related to query efficiency. The vibe I'm getting from ORM + experts is that if you really know a particular ORM, you can fine-tune the + queries it makes. There are, however, various pitfalls to avoid: + Anti-patterns to eschew, idioms to follow, particular APIs to keep clear of, + certain parameter values to explicitly pass, etc. +
++ Which strikes me as ironic, because wasn't the whole promise of ORMs that + you could read from and write to a relational database without getting + bogged down in the details of + SQL? +
++ So instead of fiddling with a temperamental and implicit ORM API, why not + write fine-tuned parametrized SQL queries? Or rather, ask an LLM to do that + for you, as well as all the boilerplate code. +
++ You should, of course, remind it to avoid + SQL injection + vulnerabilities. +
- qfilip, thank you for writing. There's nothing inherently wrong with automated tests that involve a database, as long as the tests in question are deterministic, independent, and run fast. Some people have problems with the independence property, which may be one reason why you often run into the sentiment that integration tests aren't real unit tests. -
-- Well, I wouldn't categorize them as unit tests either, but the name isn't that important. What matters is what value you get out of them, at what cost. -
-- The cost of the test is typically the other issue associated with including a real database in automated tests: They tend to be slow. If the entire test suite runs for more than ten seconds, it tends to become a problem. Even so, if this happens, you can always divide the test suite into a fast developer/TDD suite, and a slower, more complete QA suite, as described in Code That Fits in Your Head. -
-- As to whether most SQL operations are basic CRUD, I suppose that depends on context and what kind of applications you are being asked to develop. I've worked on several projects that mostly involved a lot of complicated queries. -
-+ qfilip, thank you for writing. There's nothing inherently wrong with + automated tests that involve a database, as long as the tests in + question are deterministic, independent, and run fast. Some people have + problems with the independence property, which may be one reason why you + often run into the sentiment that integration tests aren't real unit + tests. +
++ Well, I wouldn't categorize them as unit tests either, but the + name isn't that important. What matters is what value you get out of + them, at what cost. +
++ The cost of the test is typically the other issue associated with + including a real database in automated tests: They tend to be slow. If + the entire + test suite runs for more than ten seconds, it tends to become a + problem. Even so, if this happens, you can always divide the test suite into a + fast developer/TDD suite, and a slower, more complete QA suite, as + described in + Code That Fits in Your Head. +
++ As to whether most SQL operations are basic CRUD, I suppose that depends + on context and what kind of applications you are being asked to develop. + I've worked on several projects that mostly involved a lot of + complicated queries. +
++ Stephen Cleary, thank you for writing. I take it you are already + familiar with Ted Neward's article + The Vietnam of Computer Science? +
+- Stephen Cleary, thank you for writing. I take it you are already familiar with Ted Neward's article The Vietnam of Computer Science? -
-+++ As to whether most SQL operations are basic CRUD, I suppose that + depends on context and what kind of applications you are being asked + to develop. I've worked on several projects that mostly involved a lot + of complicated queries. +
+ +
+ Just to clarify again, in order to have a complicated query, one needs + some data to query against. So the reading part can be complex. + Writing, in my humble experience, is usually straightforward and EF does + a great job there. +
++ Maybe calling EF an ORM might be a misnomer, because it does much more + than just mapping. After all, it has a framework in its name. +
++ I agree that for anything beyond basic joins, it absolutely cannot + compare to SQL, because SQL has a very specific purpose. But it still + automates a lot. I'm yet to hear a compelling reason to ditch that + automation. +
++ Aside from mapping, (oh the mapping 😉), my other problem is the + maintenance of SQL as a magic string in F#/C#/whateverlang. LLMs can + generate code, but I don't trust them when something needs updating + (e.g. field name change). We can of course catch such errors with tests, + but why would I bother having them in the first place if I can relegate + it to the compiler and type checking? +
+
@@ -134,16 +167,16 @@
Comments
I've always been skeptical of ORMs because they're trying to make seamless a translation between objects (graphs) and relational tables. - Those are two different designs, so the translation layer will always - be a leaky abstraction. SQL is designed around relations, and deriving - SQL from graph relationship is always going to have edge cases in - addition to complexity and performance issues. + Those are two different designs, so the translation layer will always be + a leaky abstraction. SQL is designed around relations, and deriving SQL + from graph relationship is always going to have edge cases in addition + to complexity and performance issues.
Indeed, modern ORM usage has focused more on simple CRUD operations, - abandoning object graphs in favor of DTOs, and even using multiple - DTOs for different queries over the same tables. We ended up writing - SQL indirectly in DTOs. + abandoning object graphs in favor of DTOs, and even using multiple DTOs + for different queries over the same tables. We ended up writing SQL + indirectly in DTOs.
This is why I prefer micro-ORMs like @@ -156,32 +189,113 @@
Comments