#9964: Transaction middleware closes the transaction only when it's marked as
dirty
---------------------------------------------------+------------------------
Reporter: ishirav | Owner:
mtredinnick
Status: assigned | Milestone: 1.1
Component: Database layer (models, ORM) | Version: 1.0-beta-1
Resolution: | Keywords:
transactions
Stage: Accepted | Has_patch: 1
Needs_docs: 1 | Needs_tests: 0
Needs_better_patch: 0 |
---------------------------------------------------+------------------------
Comment (by shai):
Two words on testing:
A) The tests introduced are not for the transaction-policy setting per se,
but rather for the transaction middleware. It had none, so I figured it
could use one while I'm at it.
B) Testing this patch has to be done with two different settings files;
one where the Transaction Policy was set to safe, and one where it was
left as fast_select. This is because of a minor technicality(1) and a
major effect.
The minor technicality doesn't really matter, because of the major effect:
When you change something as fundamental as transactional behavior, it's
not enough to check your own puny unit-tests; you need to verify that you
haven't broken some innocent victim elsewhere. So, I had to run the whole
test suite under the two policies anyway; indeed, I had to fix one of the
tests(2) for it to pass.
This may look like I'm now proposing that, for all eternity, tests must be
thus run twice. Not so; I hope to see, within a couple of versions, that
fast_select is recommended against, then the default changed to safe, and
fast_select relegated to a status of not-really-supported, much like the
TRANSACTIONED_MANAGED knob is today (turning that undocumented knob in
your settings file makes the test suite fail completely, as it cannot even
syncdb a test database).
(1) The minor technicality is that the way the code is currently written,
it modifies the transaction module's global namespace (for speed); this
means it does not support changing the Transaction Policy on the fly. In
practice, one does not expect this sort of setting to change in mid-
operation; in a test setting, it seems to get in the way, but, as
mentioned above, it doesn't really matter.
(2) That test I had to fix reveals one weak point of the 'safe'
transaction policy -- if all transactions are considered dirty at all
times, there's no way to know if a transaction is pending. Thus, we lose a
validity check we currently have (where if a transaction is left pending,
an exception is thrown). I added a rollback to the end of all
transactions, as a minimal protection against such strays.
--
Ticket URL: <http://code.djangoproject.com/ticket/9964#comment:11>
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
-~----------~----~----~----~------~----~------~--~---
