#2227: transaction.commit()/rollback() should be aware of nested calls to
transaction.managed(True)
-------------------------------------+-------------------------------------
Reporter: mderk@… | Owner: nobody
Type: New | Status: assigned
feature | Component: Database layer
Milestone: | (models, ORM)
Version: SVN | Severity: Normal
Resolution: | Keywords: transaction, nest,
Triage Stage: Accepted | scope, nested, rollback, commit
Needs documentation: 0 | Has patch: 1
Patch needs improvement: 1 | Needs tests: 0
-------------------------------------+-------------------------------------
Comment (by Glenn):
Some serious breakage on this tracker ("Submission rejected as potential
spam (BlogSpam says content is spam
(badip:state/blacklist.d/127.0.0.1))"); trying again...
Replying to [comment:27 etianen]:
> However, for backends which do not support savepoints, what would the
fallback be? The only thing I can think of is to check for nesting and
only allow transactions to commit in the outer nested block. This means
that different backends will behave very differently, massively breaking
the abstraction.
What backends don't support savepoints? Postgresql, SQLite, Oracle and
MySQL all do. They're an essential part of transaction support; I
wouldn't consider any database that doesn't support them as production
quality.
> This decorator (with a better name), would work like commit_on_success,
but only actually perform the commit when the outer block exits. The
optional savepoint=True parameter would provide more fine-grained rollback
support using savepoints, but generate a warning on backends which do not
support savepoints.
There's a weird aspect of savepoints to consider:
Most of the time, using or not using savepoints makes no difference to the
code within the (sub-)transaction. The difference is to the calling
function. If a function throws an exception, whether savepoints were in
use or not determines how the *caller* needs to respond to the exception.
If savepoints were used, then the caller can catch the exception normally,
like any exception, and possibly swallow it and keep going. If savepoints
weren't used and the caller was already in a transaction, then the caller
can't do that--the exception actually means "the surrounding transaction
is invalid", and you have to roll all the way back to the origin of the
transaction to roll it back.
This means that, most of the time, the function itself doesn't care
whether it's within a savepoint or not. It's the *caller* who cares. In
other words, specifying savepoint=True or False in the decorator doesn't
really make sense to me--I can think of no case where I'd ever say False.
It's reasonable to use a new decorator for this, since doing this changes
the API of functions that use it, but having it default to not using
savepoints seems broken and I'm not sure there's much benefit to having a
parameter to disable it at all.
--
Ticket URL: <http://code.djangoproject.com/ticket/2227#comment:28>
Django <http://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" 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-updates?hl=en.
