One could lament that the real issue is the (maybe not so) accidental complexity (and hidden deep down complexity lies insecurity) that results when you're usin

One could lament that the real issue is the (maybe not so) accidental complexity (and hidden deep down complexity lies insecurity) that results when you're using utter non-sense like an ORM. The very concept of an ORM is broken. I know most devs don't know SQL well enough to do more code directly from SQL and I know most devs don't know anything else than SQL... But it's a bit sad to see all these "frameworks" tailored to the masses. dev: "I want objects. I don't really understand set theory but I still want SQL because it's all I know." chef: OK, here's a framework doing nearly everything from you. Seriously guys. Mixing orthogonal concepts and posting provocatively titled blog entries like "OO and SQL aren't orthogonal concepts, there's no mismatch impedance" ain't going to help. The only thing this creates is a lot of needless complexity and, of course, there shall always be major SNAFU like this one. Maybe, just maybe, that we could realize that if the reader is set to "from now on do not eval anymore" code shall not be eval'ed? And maybe, just maybe, that we could realize that if you're not using SQL you're not subject to these monthly SQL injections issues? How far does the SNAFU need to go for you to consider that OO + SQL is actually a very, very poor mix?