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.
On Wednesday, February 25, 2015 at 1:34:34 PM UTC+1, Thomas Recouvreux
wrote:
>
> 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.
>
>
>
>
>
>
> On Tuesday, February 24, 2015 at 4:42:52 PM UTC+1, Markus Holtermann wrote:
>>
>> 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
>>
>> On Tuesday, February 24, 2015 at 3:11:08 PM UTC+1, Marc Tamlyn wrote:
>>>
>>> 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.
>>>
>>> On 24 February 2015 at 14:04, Marten Kenbeek <marte...@gmail.com> wrote:
>>>
>>>> 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 <marte...@gmail.com>
>>>>> 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 <marte...@gmail.com>
>>>>>>> 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 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
>>>>>>>> <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 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/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 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/ffd65e43-446b-4032-a31d-da699c0678ce%40googlegroups.com
>>>>
>>>> <https://groups.google.com/d/msgid/django-developers/ffd65e43-446b-4032-a31d-da699c0678ce%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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@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/347b65c1-2793-4347-b1cf-411499991a57%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
