Chris,
What about this, from Django middleware docs:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Transaction middleware
class django.middleware.transaction.TransactionMiddleware
Binds commit and rollback to the request/response phase. If a view
function runs successfully, a commit is done. If it fails with an
exception, a rollback is done.
The order of this middleware in the stack is important: middleware
modules running outside of it run with commit-on-save - the default
Django behavior. Middleware modules running inside it (coming later in
the stack) will be under the same transaction control as the view
functions.
Tying transactions to HTTP requests
The recommended way to handle transactions in Web requests is to tie
them to the request and response phases via Django’s
TransactionMiddleware.
It works like this: When a request starts, Django starts a
transaction. If the response is produced without problems, Django
commits any pending transactions. If the view function produces an
exception, Django rolls back any pending transactions.
To activate this feature, just add the TransactionMiddleware
middleware to your MIDDLEWARE_CLASSES setting:
MIDDLEWARE_CLASSES = (
'django.contrib.sessions.middleware.SessionMiddleware',
'django.middleware.common.CommonMiddleware',
'django.middleware.cache.CacheMiddleware',
'django.middleware.transaction.TransactionMiddleware',
)
The order is quite important. The transaction middleware applies not
only to view functions, but also for all middleware modules that come
after it. So if you use the session middleware after the transaction
middleware, session creation will be part of the transaction.
An exception is CacheMiddleware, which is never affected. The cache
middleware uses its own database cursor (which is mapped to its own
database connection internally).
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Mark
On Aug 2, 5:30 pm, Chris Moffitt <[email protected]> wrote:
> > Core devs:
> > Any reason not to use database transactions to make sure we don't end
> > up with incomplete/corrupted data? I don't have any evidence that
> > would have saved my bacon in this particular case. But in the process
> > of investigating I noticed how many complex views there are creating
> > several different types of objects in one go but are not wrapped in a
> > transaction.
>
> Losing data or having data in an inconsistent state is certainly very bad.
> In general, transactions would make sense but as you mention it will be hard
> to verify that more explicit transaction management would fix the issue.
>
> So, to answer your question, forking and starting a branch with improved
> transaction management would be fine. I would just want to make sure we're
> smart about where it's used and not just using the shotgun approach to
> trying to solve the problem.
>
> -Chris
--
You received this message because you are subscribed to the Google Groups
"Satchmo users" 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/satchmo-users?hl=en.
