On 9 August 2016 at 14:29, Ben Finney <[email protected]> wrote:
> Anthony Briggs <[email protected]> writes: > > > Or you can do it the Right Way(tm) and write a custom database router > > I appreciate the advice, but no, a database router is *not* right for > this. Specifying the database routing policy in a configuration file is > no use to me; the database is not known at configuration time, and I'm > not talking about multiple simultaneously-connected databases. That is > not the use case. > > Rather, I'm wanting to specify *exactly one* database at *run-time*, and > have the operation use *that* database only (or fail if it can't). The > configured multi-database routing is no use for that. > You seem to be very focused on one specific, tactical thing which cuts across the grain of how Django works. You can get what you want, but it involves hollowing out ModelForm and replacing most of the code to couple it to the database. OTOH, the router is just a class whose methods return strings, so you can make it do whatever you want. About the only thing I'm not 100% sure on is how to find the router instance at run time, but once you have that, you can swap your db_alias='foo' for router.set_database('foo'). ConnectionRouter or django.db.router is possibly the place to start looking (https://github.com/django/django/blob/master/django/db/utils.py#L237 or https://github.com/django/django/blob/master/django/db/__init__.py#L18) -- > \ “People are very open-minded about new things, as long as | > `\ they're exactly like the old ones.” —Charles F. Kettering | > _o__) | > Ben Finney > Also, your sig is pretty amusing in context :)
_______________________________________________ melbourne-pug mailing list [email protected] https://mail.python.org/mailman/listinfo/melbourne-pug
