Ian, thanks for the feedback, but what your concern is not related to
this proposal.
What you're talking about is issuing a BEGIN while already in a database
transaction, which is normally an error, with no standard meaning or
definition in SQL's transaction model. It's completely up to the
database what happens: MySQL will implicitly commit and start a new
transaction, as you point out, but (for example) PostgreSQL will just
issue a warning and ignore it, and SQLite will fail with an error.
Django never tries to do this, and never should.
What the original message talks about is how transactional blocks marked
in Python translate to SQL transactions. This is something every SQL
abstraction layer does somewhere: the canonical way is to associate the
execution of each transactional block with a corresponding SQL
transaction, and (because execution nests but SQL transactions cannot)
most frameworks support nested transactional blocks by subsuming them,
associating their execution with the context's existing SQL
transaction.[1] This is what Django currently does, modulo the bugs
described in my original message.
The proposal is to fix these bugs, making Django fully and reliably
transactional. There are no database portability implications: Django's
transaction management will continue to work with any backend as before.
[1] This is sound because inner extents retain transactional (ACID)
semantics as part of the outer extent: no integrity is lost.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
