>"Any sufficiently complicated database-using app has a buggy implementation of half an ORM with major cache-consistency problems, some broken/outdated assumpti

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