1. When it comes to middleware implementations, that's a feature, not a bug. Inside your views, do what you want, they are either a short to medium size functio

1. When it comes to middleware implementations, that's a feature, not a bug. Inside your views, do what you want, they are either a short to medium size function, or a small class. In your templates, I agree, so don't call ORM functionality from there directly. You can also just pass a `"books": tuple(books_queryset)` to the template engine to avoid having them be able to add additional filter conditions. 2. Different way of thinking, but there are lots of times when you need to explicitly call object1.save() but not object2.save() quite yet. I think having a Session.commit() and Session.rollback() might be helpful, and I'd love clean/dirty tracking. Currently, figuring out of a given instance of a model is clean is a PITA and is often times necessary. 3. I have never felt this was a problem, from the point of view that certain types of code should not change state, so just don't do it. If you don't trust your code to not change state from under you, then why are you writing such code? 4. Agreed. I usually throw all my models into a single `core` app, and the rest of the functionality lives elsewhere. This gives me a nice separation between business logic and database storage logic too. 5. Seems like a small annoyance you deal with once. Also having a model per file feels super wasteful in terms of a model that contains no logic, no custom manager, just a half dozen fields. Hunting through files and dealing with circular imports sucks way more than having slightly longer files.