id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
32788	Transaction APIs do not consult the DB router to choose DB connection	Aditya N	nobody	"From the Django docs, for any ORM query made, the DB alias to use is determined by the following rules:

- Checks if the `using` keyword is used either as a parameter in the function call or chained with `QuerySet`.
- Consults the DB routers in order until a match is found.
- Falls back to the default router which always returns `default` as the alias.

Using the router scheme works perfectly for ORM queries. However, when it comes to using transaction APIs ​(like the transaction.atomic construct), it becomes mandatory to specify the `using` kwarg explicitly in all of its publicly exposed APIs if a DB other than the `default` alias has to be chosen. 

To illustrate why this is a problem, consider the following scenario:
- A DB router exists such that it directs queries to a specific database based on a value set in ''thread-local'' storage by a middleware.
- When ORM queries from within the view are fired, they automatically get forwarded to the right DB **without explicitly citing** the `using` keyword owing to  the router.
- But if the transaction.atomic construct is used, the `using` keyword would have to be explicitly specified each time. While this might seem fine, it creates the following problems:
  i. For large code bases, it becomes highly unwieldy to make sure that the `using` keyword has been mentioned in every transaction API call. Also, if one tries to implement the above scheme in an already existing code base, it would be impractical to add the `using` keyword in all lines calling the transaction APIs.
  ii. It doesn't gel well with the the routers framework. 

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. 

If we can finalise on this, I could submit a PR for the same."	New feature	closed	Database layer (models, ORM)	3.2	Normal	needsinfo	transaction API atomic DB router	Aditya N	Unreviewed	0	0	0	0	0	0