#32788: Transaction APIs do not consult the DB router to choose DB connection
-------------------------------------+-------------------------------------
     Reporter:  Aditya N             |                    Owner:  nobody
         Type:  Bug                  |                   Status:  new
    Component:  Database layer       |                  Version:  3.2
  (models, ORM)                      |
     Severity:  Normal               |               Resolution:
     Keywords:  transaction API      |             Triage Stage:
  atomic DB router                   |  Unreviewed
    Has patch:  0                    |      Needs documentation:  0
  Needs tests:  0                    |  Patch needs improvement:  0
Easy pickings:  0                    |                    UI/UX:  0
-------------------------------------+-------------------------------------

Comment (by Simon Charette):

 Thank you for your detailed report but
 [https://docs.djangoproject.com/en/3.2/internals/contributing/bugs-and-
 features/#requesting-features this feature request would likely get more
 feedback exposure on the mailing list].

 > A proposed work around could to be to add a separate method named
 db_for_transaction to the routers framework which would be consulted by
 the transaction APIs first, before falling  back to using the default DB
 alias.

 Can you think of places where this `db_for_transaction` hook would differ
 in any way from what `db_for_write` returns? That's what Django uses
 internally in such instances

 1.
 
https://github.com/django/django/blob/0d67481a6664a1e66d875eef59b96ed489060601/django/db/models/base.py#L745-L760
 2.
 
https://github.com/django/django/blob/0d67481a6664a1e66d875eef59b96ed489060601/django/db/models/base.py#L950
 3.
 
https://github.com/django/django/blob/0d67481a6664a1e66d875eef59b96ed489060601/django/db/models/deletion.py#L400

 I get that your asking for a way to avoid explicitly passing
 `atomic(using)` all over the place but I'm having a hard time figuring out
 in which cases a `db_for_transaction` hook, which cannot be provided any
 contextual details like other router methods do, can take an an advised
 decision without relying on global state/thread locals.

 Maybe that a better API would be a `transaction.default_database(using:
 str)` context manager that abstracts the context state encapsulation?

-- 
Ticket URL: <https://code.djangoproject.com/ticket/32788#comment:3>
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 [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/069.ff4048ab572cb558be6fb53c05281c8b%40djangoproject.com.

Reply via email to