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.
On Tuesday, February 24, 2015 at 2:52:47 PM UTC+1, Marc Tamlyn wrote: > > In that case your proposal sounds perfectly reasonable. > > On 24 February 2015 at 13:47, Marten Kenbeek <[email protected] > <javascript:>> wrote: > >> 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`. >> >> On Tuesday, February 24, 2015 at 2:43:51 PM UTC+1, Marc Tamlyn wrote: >>> >>> 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 >>> >>> On 24 February 2015 at 13:38, Marten Kenbeek <[email protected]> wrote: >>> >>>> With recent bug reports (#24332 >>>> <https://code.djangoproject.com/ticket/24332>, #24298 >>>> <https://code.djangoproject.com/ticket/24298> and now #24394 >>>> <https://code.djangoproject.com/ticket/24394>) all caused by setting >>>> `DATABASES['default'] = {}`, this makes me wonder if it should be >>>> supported >>>> at all. >>>> The documentation states: >>>> >>>> The DATABASES >>>>> <https://docs.djangoproject.com/en/dev/ref/settings/#std:setting-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 >>>> >>>> -- >>>> 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 [email protected]. >>>> To post to this group, send email to [email protected]. >>>> 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 >>>> <https://groups.google.com/d/msgid/django-developers/756eefc2-1baf-4898-91bf-86d378a27b04%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> -- >> 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 [email protected] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> 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/d8373cb4-27c8-40ea-85b0-c144530b1180%40googlegroups.com >> >> <https://groups.google.com/d/msgid/django-developers/d8373cb4-27c8-40ea-85b0-c144530b1180%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> > > -- 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 [email protected]. To post to this group, send email to [email protected]. 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/ffd65e43-446b-4032-a31d-da699c0678ce%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
