#22802: update Atomic class to make use of public transaction module-level API
functions
-------------------------------------+-------------------------------------
Reporter: gwilson | Owner: gwilson
Type: | Status: assigned
Cleanup/optimization | Version: 1.6
Component: Database layer | Resolution:
(models, ORM) | Triage Stage:
Severity: Normal | Unreviewed
Keywords: | Needs documentation: 0
Has patch: 0 | Patch needs improvement: 0
Needs tests: 0 | UI/UX: 0
Easy pickings: 0 |
-------------------------------------+-------------------------------------
Comment (by gwilson):
Agree that the solution here is more pragmatic, rather than ideal. It
does, in fact, make the Atomic class inconsistent in that it accesses both
the module-level functions and the connection object directly. That said,
it also makes the transaction code paths more consistent, while still
ultimately making use of the methods on the connection object.
For a longer term solution, we should solidify a transaction API to use
and make it possible customize the behavior/implementation without the
need for third-party libraries to monkey-patch and/or recreate multiple
connection class hierarchies.
Possible solutions may include:
* Maintain the transactions module, using either the existing functions or
a new class. The latter would be desirable as it would be easy to then
expose that as a database setting.
* Deprecate the functions in the transactions module, and instead make use
of the DatabaseWrapper methods directly. The heart of the transaction
management code lives in the DatabaseWrapper objects anyway; however,
database settings currently only allow specifying the engine module,
meaning that to swap out a customized DatabaseWrapper subclass would mean
creating a custom engine package with a base.py module, etc. importing the
original classes for everything but the custom DatabaseWrapper.
* Factoring out a base transaction management class that gets composed
into the DatabaseWrapper instances. This is similar to the first item,
except the idea here would be to actually contain the meat of the
transaction management code instead of just a light wrapper around the
connection object. This class, too, could then be something that could be
swapped out with a database setting; however, they may still be
complexities with class hierarchy should different database backends
require custom transaction management classes.
That said, for a long-term solution, we should open a new ticket.
--
Ticket URL: <https://code.djangoproject.com/ticket/22802#comment:7>
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/065.d2fc4b6cadb45de70589b60d3f6b6224%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
