> One reason not to do this is that it simply isn't standard behaviour for > Python database adaptors (they must be in non-autocommit mode > initially). So there's a principle of least-surprise thing going on.
I'm not convinced by the argument of least-surprise. As you said, there are explicit commit_unless_managed() calls inside the Django internals (e.g. inside save() ) - but a Django _user_ (rather than developer) would not have read this code before calling save(). So, a Django user who expects Python database adaptors to be non-autocommit is _already_ being surprised by the fact that save() behaves as if it is. By designing default Django behaviour to be "similar to auto-commit", I think we've already decided that the DB-API default is wrong. It's now a case of how Django implements the "similar to auto-commit" behavior most cleanly and efficiently. I think the answer is: - Get auto-commit connections from Python database adaptors by specifically requesting them - Delete all of the commit_unless_managed() calls - Change enter_transaction_management() / transaction.managed(True) to explicitly issue an SQL BEGIN - Change leave_transaction_management() / transaction.commit / transaction.rollback to explicitly issue SQL COMMIT / ROLLBACK I suspect that this will significantly simplify the Django codebase vs. trying to simulate both auto-commit and transaction behaviors on top of a transactional connection - it would certainly remove most of the mechanisms in django/db/transaction.py which track state, dirty, etc. Cheers, Richard. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
