Re: Unintuitive behaviour of management commands with multiple databases

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBCAAGBQJWsQh6AAoJEC0ft5FqUuEhOHAQAKGhlNzhg1znnvvPSFEO6rlX
RE67TJW1W3Ks+cq3xborzSZwkNbx8eH5luBnm8sBd2Jcm5FL/167xLwaVCzvtIyL
faDFdWn8EDv9HHCELzbwtcydsxAe2WYIVNkf2rDYz/hpHeHX1h0h9SQTtSjszPiM
TGwKpw0iksWcFdbKpUEb+q5bLTcKH2/hx4wCBHHk4kz5PHxyeTOV5OZeHyuEozOz
3t6wSmW80Lex0j2qzKPKddWcbl4r42TH2EO1QIwave/7mFFy19uislf5X4jTVTlk
2kI/ZNjfZ3K9WJl/+ICZKM5PFSTcPiEmSvaSWoJ6e2QSRX29YUkHMf0HvHRXyDNE
9gw8HkX9foMRFj6JKKf0y2l4ifh4XaGhWlvdNNfod3XroxfJWnENkJrS7Gt99J4B
ikWkEQKBkj8gf44Uo9wfbmGBzz9wCWyH3fSiOGJIToh4ex+rZPK+JdQKPp2GLx52
31IXp0VzYX+f0V4Lrxn0gFboViwG0SzdLwShdua2KfZA1oAAdOwGuAwrqHiDq+aH
BXxv2nbkYq/VJME+3SpO/+H2VdPkIrV7jT46nPtNqKrEPSBG5GTQs/Bk6PSDdWCk
cyULQdPIl0MqWoDphhKv1+OtZiKhgKVCake1gvAbNwMDwzAMhL9riOStvAWdEDxS
lJXpEk44b4KDi7RJAI+S
=yJV/
-----END PGP SIGNATURE-----
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 as the default database to use just for that command
> invocation, when that value is different to whatever
> settings.DATABASES['default'] is. A quick look at the builtin management
> commands shows there's a lot of usage
> of connections[options.get('database')] going on, and yet externally
> written management commands aren't encouraged to use the same approach,
> and multiple settings files are the suggested alternative?

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 useful
because they need to do low-level things with the connection; I don't
think it helps you for regular ORM use. It doesn't allow changing the
default connection for ORM usage. Where the built-in management commands
do use the higher-level ORM, they use the public `using` APIs.

In other words, the built-in management commands aren't doing anything
different from what I originally recommended you do (just use `using`).

If you want to write a management command that has a --database option
like the built-in ones and makes heavy use of the ORM, you can a)
explicitly provide `using` where needed , b) use
django-dynamic-db-router, or c) hold your nose and monkeypatch
DEFAULT_DB_ALIAS, since it's just a one-shot management command and you
don't need to be as concerned about cleaning up after yourself.

Personally I would go for (a) or (b), depending on just how much I was
using the ORM in the management command. I'm not convinced that a fourth
(or third supported public) option is necessary here. If it's just a few
queries, you use `using`, if it's more than that and you want a broader
policy applied, you use a database router.

Carl

--
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+unsubscribe@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/56B10877.10900%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.