#33161: Do not ignore transaction durability errors within TestCase
-------------------------------------+-------------------------------------
Reporter: Krzysztof Jagiełło | Owner: Krzysztof
| Jagiełło
Type: New feature | Status: assigned
Component: Testing framework | Version: dev
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by David Seddon):
Thanks for looking into this!
We've been using a hand-rolled equivalent of `durable=True` extensively
for a couple of years on a large code base. Our implementation consults a
setting which we typically override along the lines of
`@override_settings(DISABLE_DURABILITY_CHECKS=True)`. Two years in, I
don't think there's been much value in requiring the override for each
relevant test, and I imagine we'll switch to using a global setting (at
least for the transaction-wrapped test cases which, conveniently, use a
different configuration to the unwrapped ones).
So on balance I think it makes more sense to disable the behaviour than
require developers to turn it off on a test-by-test basis, though it
''might'' be worthwhile providing a setting so that people can choose the
default behaviour.
Having said that, there is a downside which reminds me of the difficulties
of testing code that uses `select_for_update`. I have seen many occasions
where wrapped test cases are the only coverage of such code, and we don't
see the issue until it hits production. If we just turn off the checking
wholesale, it's more likely that unrunnable code will make its way onto
production.
An even better solution would be for wrapped TestCases to be able to tell
the difference between the transaction begun by the TestCase itself and
any subsequent atomic blocks entered. They would then allow durable blocks
to be entered providing the only block we're in is that initial block
(possibly this is what has been implemented, I wasn't able to tell at
first glance).
--
Ticket URL: <https://code.djangoproject.com/ticket/33161#comment:14>
Django <https://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 unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/067.1701f5c7335d133ba81f81fb09eb7512%40djangoproject.com.
