3 ms·

I'm the last person to want to really defend ORMs. But there's a flavor of Greenspun's Tenth Rule [1] that applies... it would go something like "Any sufficien

I'm the last person to want to really defend ORMs. But there's a flavor of Greenspun's Tenth Rule [1] that applies... it would go something like "Any sufficiently complicated database-using app has a buggy implementation of half an ORM with major cache-consistency problems, some broken/outdated assumptions about the schema, and a few SQL injection holes you could drive a truck through." A decent ORM can help manage the impedance mismatch between SQL and the app language. ORMs are very leaky abstractions and definitely restrict design, but metaprogramming SQL in an app language has its own drawbacks. [1] https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule

aeorgnoieang 9y ago
This has been my experience as well. Being very comfortable with SQL, I initially thought very poorly of ORMs, especially given that my first major exposure was to a "buggy" half-hand-baked implementation. But, like a lot of other things, they definitely exist for a reason and can often be the best option given the particular tradeoffs you're given.
Terr_ 9y ago
That's my experience with a certain 10+ year old piece of PHP enterprise software. Not only is the ORM homegrown, but it started as a data-mapper and somehow ended up being used in a degenerate way like active-record, and has lot of "fun" quirks.
lowbloodsugar 9y ago
>"Any sufficiently complicated database-using app has a buggy implementation of half an ORM with major cache-consistency problems, some broken/outdated assumptions about the schema, and a few SQL injection holes you could drive a truck through." Inherited a product that used an ORM. The application was a java application running on multiple hosts and non-sticky sessions. It used session caching, which round-robin load balancing broke silently. Hah, no I'm kidding! It used global caching! Then it was replete with transaction annotations, but it was the wrong transactional level and the transactional annotations were not configured to be used anyway. Then the schema was hard-coded (which I'd usually say is a good thing) because they'd had the database fall over when the ORM attempted to update the schema. Of course the hard-coded schema was missing things and only fixed when the, now manual, updates to the DB caused the queries to outright fail. While the ORM prevented SQL injection, the belief that the ORM somehow handled any kind of injections, meant that the outputs weren't sanitized and XSS injections were not handled at all. So perhaps the problem isn't SQL or ORMs, its that some programmers don't know what the fuck they are doing, and ORMs make it easier to postpone that enlightenment, sometimes indefinitely.

aeorgnoieang 9y ago

This has been my experience as well. Being very comfortable with SQL, I initially thought very poorly of ORMs, especially given that my first major exposure was to a "buggy" half-hand-baked implementation. But, like a lot of other things, they definitely exist for a reason and can often be the best option given the particular tradeoffs you're given.

Terr_ 9y ago

That's my experience with a certain 10+ year old piece of PHP enterprise software. Not only is the ORM homegrown, but it started as a data-mapper and somehow ended up being used in a degenerate way like active-record, and has lot of "fun" quirks.

lowbloodsugar 9y ago

>"Any sufficiently complicated database-using app has a buggy implementation of half an ORM with major cache-consistency problems, some broken/outdated assumptions about the schema, and a few SQL injection holes you could drive a truck through." Inherited a product that used an ORM. The application was a java application running on multiple hosts and non-sticky sessions. It used session caching, which round-robin load balancing broke silently. Hah, no I'm kidding! It used global caching! Then it was replete with transaction annotations, but it was the wrong transactional level and the transactional annotations were not configured to be used anyway. Then the schema was hard-coded (which I'd usually say is a good thing) because they'd had the database fall over when the ORM attempted to update the schema. Of course the hard-coded schema was missing things and only fixed when the, now manual, updates to the DB caused the queries to outright fail. While the ORM prevented SQL injection, the belief that the ORM somehow handled any kind of injections, meant that the outputs weren't sanitized and XSS injections were not handled at all. So perhaps the problem isn't SQL or ORMs, its that some programmers don't know what the fuck they are doing, and ORMs make it easier to postpone that enlightenment, sometimes indefinitely.