I’ve been working on a spec for months. Finally…every stakeholder approves. I’ve cataloged every piece of code that needs to be migrated in a Notion DB. I’m working on one of the first PRs and then I see it…db.commit() “…ffffuuuuuummmmccckkkk mmmmmmeee…” The DBAccess class is slipping manual commits into nested helpers, breaking atomicity.

The rant is not about ORMs or SQL – it’s about code organization. When helper functions call commit() inside a transaction decorator, the outer context has no idea that a write already happened. The result is data loss or silent writes that only appear when the transaction ends. Even passing DBModel objects around and mutating them triggers hidden writes.

To enforce the rule, use AST analysis or a flake8 plugin that flags any call to commit(). The custom test walks the AST, collects violations, and asserts none remain. This keeps the DB abstraction layer in charge of all commits, preventing accidental random commits.

The takeaway: let the database layer own transactions, avoid passing models outside it, and use linting or AI‑driven checks to catch hidden commits. For more depth, read Domain-Driven Design.