Support for DATABASES['default'] = {}

[Marten Kenbeek]

With recent bug reports (#24332, #24298 and now #24394) all caused by setting `DATABASES['default'] = {}`, this makes me wonder if it should be supported at all.

The documentation states:

The DATABASES setting must configure a default database; any number of additional databases may also be specified.[1] 

And indeed, if default is not set at all, an error is raised. If default does not provide valid database settings, it is set to use `django.db.backends.dummy`. This will raise a `NotImplementedError` as soon as it is used, but it seems you can work around this quite well and ensure that `default` is barely used. The exceptions to this are reported in the mentioned bug reports, most notably `manage.py test` uses the `default` database. 

Should the documentation be clarified that it not only requires `default` to be set, but that it requires a valid database configuration as well? Or should an empty `default` configuration be valid?

In #24332 and #24398, both fixed now, there was the additional issue that the code was simply not using the database is was supposed to use.

I think this mostly boils down to whether we want the `test` command to support an explicit non-default database, you should be able to manipulate all other code to only use non-default databases, save some similar bugs that might still be present. This would reduce `default` to simple semantics and would probably warrant that it is no longer required if you supply an otherwise valid database configuration. However, I don't see any drawbacks to requiring a valid database setup. At most this would require developers to copy the credentials from the database they are actually using to the `default` setting, but it would also be an incentive to actually use `default` as the default database. 

[1]  https://docs.djangoproject.com/en/dev/ref/settings/#databases

[Marc Tamlyn]

It would seem more sensible to me to try to support DATABASES={}. There's no reason why a Django site should have to run a database - a microservice using redis or something similar is perfectly reasonable and you could want to use Django for other reasons (e.g. shared templates).

Marc

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/756eefc2-1baf-4898-91bf-86d378a27b04%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Marten Kenbeek]

In fact, DATABASES={} is a valid configuration and merely sets 'default' as a dummy backend. An exception is only explicitly raised if you supply a non-empty setting that does not include `default`. 

[Marc Tamlyn]

In that case your proposal sounds perfectly reasonable.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/d8373cb4-27c8-40ea-85b0-c144530b1180%40googlegroups.com.

[Marten Kenbeek]

Which one? :P This was more intended as a question than as a proposal.

I personally prefer a documentation change and strict checking of `default` if and only if the database configuration is not empty. django.db.connection relies on the default connection, and third-party apps which (intentionally or unintentionally) do not support multi-db setups might be using that. I can't think of a scenario where it hurts to have a default database. I'm easily swayed on this matter, though. 

[Marc Tamlyn]

I can't see why it is sensible to support an invalid database configuration as the default. If you explicitly want the default to be a dummy, you should configure that IMO.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/ffd65e43-446b-4032-a31d-da699c0678ce%40googlegroups.com.

[Markus Holtermann]

The question I'm asking myself right now: what is a "default" database in a multi database setup where "default" does not make sense at all? I can easily think of a case where I have multiple other databases used by other services where Django provides a dashboard. I don't see any of those databases being a "default".

That said, having an implicit default database that defaults to a dummy backend doesn't seem too bad. I'd rather see the docs updated in that regards and fix code that relies on "default" although giving an explicit database alias isn't complicated. "manage.py test" could get a --database option (if it doesn't have it already).

/Markus

[Thomas Recouvreux]

Hello,

I have a case where the 'default' database does not have any sense, but I still want the tests to create and manage transactions on other defined databases, so the option `--database` would not help me. I could put something in the default database like in memory sqlite for the tests but it does not feel good to me since this could lead to successful tests but failures on production environment.

Would it be possible to remove the requirement of the 'default' alias ? It seems a bit odd to me that DATABASES = {} and DATABASES = { 'default': {}, 'mysite': { .. } } are valid settings but DATABASES = { 'mysite': { .. } } is not.

Whatever is the final decision, do not forget to update the doc if necessary, since the current doc (https://docs.djangoproject.com/en/1.7/topics/db/multi-db/#defining-your-databases) states DATABASES = { 'default': {} } is a valid setting.

[Marten Kenbeek]

If the docs state that it is a valid setting, then we shouldn't change that to maintain compatibility and your ticket is indeed a bug. In that case, it makes sense to me not to require the `default` database setting in the first place. The error caused in #24394 is a result of looping over all available connections, removing this requirement should fix the bug as well. 

Looking at just the traceback for this bug, it seems that, without a `default` configuration, a `--database` option in the test command is not necessary with proper routing in the application, and it wouldn't even make sense in a multi-db testing environment.