#36505: Allow overriding default database in contextmanager
-------------------------------------+-------------------------------------
Reporter: rockisch | Type: New
| feature
Status: new | Component: Database
| layer (models, ORM)
Version: 5.2 | Severity: Normal
Keywords: database router | Triage Stage:
contextmanager | Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
I would like to request a way to temporarily override the default database
name, ideally with a `contextmanager`. That is, I would like to be able to
write code like this:
{{{
with db.override("replica"):
user = User.objects.first()
with connection.cursor() as cursor:
cursor.execute(...)
}}}
and ensure all DB queries end up in the replica DB.
Currently it is somewhat possible to implement this with the current
Django featureset in a 'safe manner' by using Database Routers and
`contextvar`s ([https://forum.djangoproject.com/t/force-queries-in-a
-context-to-execute-in-the-named-database/37754/8 forum response]), but
that approach does not override `connection`/`transaction`, which can both
cause issues with 3rd party community packages, as well as being a
limitation for more 'advanced' DB features, which as mentioned by
[https://forum.djangoproject.com/t/allow-database-router-to-override-
default-connection/34529/7 this post] most users in a multi-DB scenario
are probably using such features. The alternative is to monkey-patch
Django... which is what I am doing right now, but is obviously far from
ideal.
Although I don't have a patch, the monkey-patch should more or less show
what is required for this to work:
https://gist.github.com/rockisch/96425b6aaa406dcf4fb86df92715fe1e
This would be a non-breaking change, and similar APIs exist for
[https://docs.djangoproject.com/en/5.2/ref/utils/#django.utils.translation.override
translation.override] and `timezone.override`. Using context vars allows
this feature to be isolated between async contexts. I believe this would
also solve a few issues people had in the past with Database Routers, most
of which are marked as 'wontfix' because it would break the Database
Router API.
On the other hand, as seen in the linked monkey-patch... this touches the
very core of the Django DB connection handling, and although I don't think
the overhead is significant, I don't have stats to assert so. It would
also add some extra complexity, and could break monkey-patches people did
in the past.
Here are some relevant links to discussions which would most likely be
solved by this feature:
https://forum.djangoproject.com/t/allow-database-router-to-override-
default-connection/34529/7
https://forum.djangoproject.com/t/force-queries-in-a-context-to-execute-
in-the-named-database/37754/8
https://code.djangoproject.com/ticket/35349
https://code.djangoproject.com/ticket/33578
https://code.djangoproject.com/ticket/32788
Since this is backwards compatible (aside from breaking monkey-patches) I
thought it'd make sense to open here before contacting the mailing list.
Let me know if that's required for this to be considered.
--
Ticket URL: <https://code.djangoproject.com/ticket/36505>
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 visit
https://groups.google.com/d/msgid/django-updates/010701980a78b08a-f4d3ba24-4faf-4e23-b6c9-5712f8f95a32-000000%40eu-central-1.amazonses.com.
