There's merit in both the responses.
Since it's trivial to write your own transaction middleware, I would say
the most important thing is to document that the middleware only affects
your 'default' database. Then it's up to the developer to decide if they
need anything further.
On Sun, Nov 13, 2
Before voting for more magic to the transaction middleware, I'd vote
to remove it altogether. Explicit is surely better than implicit in
this case. The admin already uses commit_on_success, etc.
On Oct 18, 1:22 pm, David Winterbottom
wrote:
> The current implementation of django.middleware.Transa
I'm not sure this is so cut and dry. For two reasons:
1) If a project has a lot of databases configured, created and ending a
transaction in all of them for every request/response cycle could get
expensive, and following that:
2) This is enough of a change in behavior that it shouldn't just be
The current implementation of django.middleware.TransactionMiddleware does
not create a transaction for each database, only the default one
defined by DEFAULT_DB_ALIAS
- https://code.djangoproject.com/browser/django/trunk/django/db/utils.py.
Shouldn't the middleware manage a transaction for each d
