Why not? Why should I be allowed to db.commit() midway through a transaction?

Show, don't tell. The article should've included an example of these helpers.

All in all, this feels poorly written, but also poorly thought out. The DB layer can and should throw an exception if you manually begin/commit inside a context manager. Please do blame it if it doesn't.

If your framework is holding your records in a collection and you keep track of phantoms that have been edited but not saved as they are edited then all this becomes a non issue. That way you do Collection->SaveTransaction or Collection->Save() and the collection does all the db commit, roll back nonsense.

Anyway the examples I don't even know if I could call that an ORM. Use a better one.

Guess our pattern is different, not really felt the pain point the author is talking about. Or it's the language/framework, not sure whatever the example code is written in, but setting properties on entity records would never update the database in the ones I've used.

When we did things more manually we'd make sure that methods like `create_main_records` would start a transaction if not in one, and only commit if it started the transaction. This way we could nest without worry. Our database supported nested transactions but using this pattern we didn't feel the need.