Discussion:
Support for DATABASES['default'] = {}
(too old to reply)
Marten Kenbeek
2015-02-24 13:38:57 UTC
Permalink
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-developers+***@googlegroups.com.
To post to this group, send email to django-***@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.
Marc Tamlyn
2015-02-24 13:43:25 UTC
Permalink
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
Post by Marten Kenbeek
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 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
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-developers+***@googlegroups.com.
To post to this group, send email to django-***@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/CAMwjO1Eo3Z8Mt14FyNJcN0Tdo0%3DNefqYwoiFJGZEp4WSg26Wnw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Marten Kenbeek
2015-02-24 13:47:39 UTC
Permalink
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`.
Post by 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
Post by Marten Kenbeek
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 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
<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/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-developers+***@googlegroups.com.
To post to this group, send email to django-***@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.
For more options, visit https://groups.google.com/d/optout.
Marc Tamlyn
2015-02-24 13:52:15 UTC
Permalink
In that case your proposal sounds perfectly reasonable.
Post by 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`.
Post by 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
Post by Marten Kenbeek
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 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
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
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-developers+***@googlegroups.com.
To post to this group, send email to django-***@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/CAMwjO1ESL5kgPvmnE7zszC5bJDm-nqbJrNFDsaTR8JFAc9JQsQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Marten Kenbeek
2015-02-24 14:04:53 UTC
Permalink
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.
Post by Marc Tamlyn
In that case your proposal sounds perfectly reasonable.
Post by 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`.
Post by 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
Post by Marten Kenbeek
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 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
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
<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 django-developers+***@googlegroups.com.
To post to this group, send email to django-***@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.
For more options, visit https://groups.google.com/d/optout.
Marc Tamlyn
2015-02-24 14:10:39 UTC
Permalink
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.
Post by 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.
Post by Marc Tamlyn
In that case your proposal sounds perfectly reasonable.
Post by 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`.
Post by 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
Post by Marten Kenbeek
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 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
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
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
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+***@googlegroups.com.
To post to this group, send email to django-***@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/CAMwjO1HMmYvUMbs7nVCDNWtCN0VKS%3DiQeCZAV0pFtXO5AhmKgA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Markus Holtermann
2015-02-24 15:42:52 UTC
Permalink
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
Post by 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.
Post by 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.
Post by Marc Tamlyn
In that case your proposal sounds perfectly reasonable.
Post by 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`.
Post by 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
Post by Marten Kenbeek
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 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,
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
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
<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/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+***@googlegroups.com.
To post to this group, send email to django-***@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/c89334d2-d334-4c84-be38-6f043363f220%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Thomas Recouvreux
2015-02-25 12:00:17 UTC
Permalink
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.
Post by 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
Post by 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.
Post by 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.
Post by Marc Tamlyn
In that case your proposal sounds perfectly reasonable.
Post by 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`.
Post by 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
Post by Marten Kenbeek
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 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,
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
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
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+***@googlegroups.com.
To post to this group, send email to django-***@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/315f5ac5-7090-49b1-a711-1c4de9e8222c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Marten Kenbeek
2015-02-25 13:27:47 UTC
Permalink
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
Post by 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.
Post by 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
Post by 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.
Post by 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.
Post by Marc Tamlyn
In that case your proposal sounds perfectly reasonable.
Post by 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`.
Post by 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
Post by Marten Kenbeek
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 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,
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,
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
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+***@googlegroups.com.
To post to this group, send email to django-***@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.
Loading...