The only difference between active record and non-active record is that with the former, there's some globally accessible database client session object that th

The only difference between active record and non-active record is that with the former, there's some globally accessible database client session object that the record objects know how to get to. There's no difference between `Author.get(id)` and `session.query(Author).get(id)` in terms of code design, data integrity or whatever. Maybe you could make the argument that by forcing you to interact with the `session` object you are encouraged to call `session.save()` which makes the transaction explicit, but I find that a thin argument. People are going to make O(n^2) mistakes like the one used as an example here regardless of whether they use an ORM. In fact, people make those sort of mistakes without even touching the database. Yes, the ability to expose query objects is super important, but there are active record libraries that do this, for example Laravel's Eloquent or Django's ORM. Seems like this article is conflating a lot of issues that aren't really related. I would re-write the whole thing as: 1. The importance of native query objects in your ORM 2. The importance of transactions 3. Traps of O(n^2) when using ORMs Don't even bring up active record.