Dear Carl, On Tuesday, February 2, 2016 at 5:08:40 PM UTC, Carl Meyer wrote: > > You can't (well, you might be able to by poking around in the internals > of the django.db.connections object, but I'd strongly advise against > that). The proper (and thread-safe) way to achieve the equivalent is to >
Well, for any given run of the application (on which the example I posted is based), only one database is ever used. The idea of multiple databases was to allow us to select which one is used for any particular Python process run, and we expected to be able to run management commands which would (based on a settings configuration) determine both which database to use and e.g. how to populate parts of it ready for deployment to particular customers. Oddly, setting django.db.utils.DEFAULT_DB_ALIAS = alias does the trick. Yes, I know that's a no-no, but it seems to me that for this kind of case where you don't need run-time routing, something like django-dynamic-db-router shouldn't really be needed, useful though it might be for the run-time routing case. Everything else works off the settings module, and the fact that Django caches the default database to use such that a management command can't change it seems like a design flaw. I suppose I was expecting transaction.atomic(using=XXX) to not just open a transaction on that database, but also make it the default for the scope of the block (except if explicitly overridden by using() for particular models in code called from that block). The current behaviour seems to violate the principle of least surprise (this my first encounter with multiple databases). Is there really no case for an in_database() context manager in Django itself? Though I would still expect that behaviour from transaction.atomic(), of course, but backwards compatibility is a constraint I'm aware of :-) Regards, Vinay Sajip -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at https://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/66079ae6-f7e8-4771-acd0-30537bcb1c84%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
