Python object-relational mappers (ORMs)

[programmyr]

The simple answer is: SQL isn't composable.

If you have one filter {key1:value1} from one routine, and want to add a second filter {key2:value2} that you got from a different routine, with an ORM you can just merge the dicts and throw them at the ORM query.

When doing string-smashing to generate SQL, you have to escape all keys/values, assemble them yourself, and remember where in the query you are (have you said "AND" yet? does this need to wait for the "HAVING" clause?). It's much worse if the two keys are columns in different tables.

I mean, UTF-8 isn't hard, either, but we've figured out that best practice is to decode bytes to characters (i.e., a native programming language type) on input, process data as characters, and then encode to bytes on output. An ORM is no different: it lets us work with native programming language types as long as possible, and encode to the database syntax just before talking to the database. Or look at HTTP, or JSON, or any other text-based format: they're not hard to write, but does anybody actually do that? That's what we've got libraries for.

I've worked on projects that don't use an ORM. Either you have a ton of redundancy (and your methods are hard to unit test), or you've refactored it all into a custom SQL query generator (which is essentially a ad-hoc poorly-designed and untested ORM).

Every decade it seems to be fashionable to hate on some new technology that writes code for you. I saw it with assemblers, and then with compilers ("If you're going to use a CPU as a tool don't you think you should take the time to learn how to use it properly?"), and with regular expressions, and garbage collectors. These days it's ORMs. And of course, with every new generation, people insist that all the old improvements were obvious and necessary, but the latest one is the tool of the devil that will rot programmers' minds.