Re: Unintuitive behaviour of management commands with multiple databases

2016-02-02 Thread 'Vinay Sajip' via Django users
Dear Carl, On Tuesday, February 2, 2016 at 7:51:20 PM UTC, Carl Meyer wrote: > > > There's nothing wrong with connections[options.get('database')] if you > want to get a specific database connection object; that's public API and > you can use it. In the case of the built-in commands, that's usef

Re: Unintuitive behaviour of management commands with multiple databases

2016-02-02 Thread Carl Meyer
Hi Vinay, On 02/02/2016 12:14 PM, 'Vinay Sajip' via Django users wrote: > I'm not arguing for any particular different routing scheme to be > included - only for management commands to be able to be written to > respect --data arguments passed to them, and which can easily treat the > passed value

Re: Unintuitive behaviour of management commands with multiple databases

2016-02-02 Thread 'Vinay Sajip' via Django users
Dear Carl, On Tuesday, February 2, 2016 at 6:23:34 PM UTC, Carl Meyer wrote: > > For this scenario, I would use a different settings file (which can all > "inherit" the same common settings via the `from common_settings import > *` trick) for each "customer", with a different default database de

Re: Unintuitive behaviour of management commands with multiple databases

2016-02-02 Thread Carl Meyer
Hi Vinay, On 02/02/2016 10:56 AM, 'Vinay Sajip' via Django users wrote: > 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 >

Re: Unintuitive behaviour of management commands with multiple databases

2016-02-02 Thread 'Vinay Sajip' via Django users
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

Re: Unintuitive behaviour of management commands with multiple databases

2016-02-02 Thread Carl Meyer
Hi Vinay, On 02/02/2016 09:52 AM, 'Vinay Sajip' via Django users wrote: > > On Tuesday, February 2, 2016 at 3:27:10 PM UTC, Carl Meyer wrote: > > Nothing in your code ever "overrides" settings.DATABASES['default']. > > > Dear Carl, > > Thanks for the quick response. I /had/ thought of tha

Re: Unintuitive behaviour of management commands with multiple databases

2016-02-02 Thread 'Vinay Sajip' via Django users
On Tuesday, February 2, 2016 at 3:27:10 PM UTC, Carl Meyer wrote: > > Nothing in your code ever "overrides" settings.DATABASES['default']. > Dear Carl, Thanks for the quick response. I *had* thought of that, and tried adding the statement settings.DATABASES['default'] = settings.DATABASES[alia

Re: Unintuitive behaviour of management commands with multiple databases

2016-02-02 Thread Carl Meyer
Hi Vinay, On 02/02/2016 08:11 AM, 'Vinay Sajip' via Django users wrote: > I've set up a simple project using with two databases, foo and bar in > settings.py: > > | > DATABASES ={ > 'foo':{ > 'ENGINE':'django.db.backends.sqlite3', > 'NAME':os.path.join(BASE_DIR,'foo.sqlite'),

Unintuitive behaviour of management commands with multiple databases

2016-02-02 Thread 'Vinay Sajip' via Django users
I've set up a simple project using with two databases, foo and bar in settings.py: DATABASES = { 'foo': { 'ENGINE': 'django.db.backends.sqlite3', 'NAME': os.path.join(BASE_DIR, 'foo.sqlite'), }, 'bar': { 'ENGINE': 'django.db.backends.sqlite3', 'NAME': o