[Django] #16752: Multi-db without a 'default' database

39 views
Skip to first unread message

Django

unread,
Sep 3, 2011, 2:34:38 PM9/3/11
to django-...@googlegroups.com
#16752: Multi-db without a 'default' database
-------------------------------------+-------------------------------------
Reporter: jdunck | Owner: nobody
Type: Bug | Status: new
Milestone: | Component: Database
Version: 1.3 | layer (models, ORM)
Keywords: | Severity: Normal
Has patch: 0 | Triage Stage:
Needs tests: 0 | Unreviewed
Easy pickings: 0 | Needs documentation: 0
| Patch needs improvement: 0
| UI/UX: 0
-------------------------------------+-------------------------------------
In the [https://docs.djangoproject.com/en/dev/topics/db/multi-db multi-db
doc] it says:
{{{
If you don’t have a default database, you need to be careful to always
specify the database that you want to use.
}}}

I have a project where that is exactly the behavior I'd prefer - I want to
explicitly route every call and have nothing go to the 'default' database.

However, when I removed the 'default' key from DATABASES (and hard-coded a
router to always return a different value), model validation failed. This
seems to be because it imports
{{{
from django.db import connection
}}}
then proceeds to validation the schema against that connection (which is,
in fact, the non-existant 'default'). This fails as soon as an operation
is called on the connection.

There is a second problem with this -- all model validation occurs against
the default connection rather than the connection that the model will be
routed to. That seems like a bug, but I'd like to treat it separately.

My intention with this ticket is to establish: do we intend projects to
work without a 'default' project, as implied by the docs, or is a
'default' database always assumed?

--
Ticket URL: <https://code.djangoproject.com/ticket/16752>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

Django

unread,
Sep 3, 2011, 3:48:38 PM9/3/11
to django-...@googlegroups.com
#16752: Multi-db without a 'default' database
-------------------------------------+-------------------------------------
Reporter: jdunck | Owner: nobody
Type: Bug | Status: new
Milestone: | Component: Database layer
Version: 1.3 | (models, ORM)
Resolution: | Severity: Normal
Triage Stage: | Keywords:
Unreviewed | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-------------------------------------+-------------------------------------
Changes (by jdunck):

* cc: eng@… (added)


--
Ticket URL: <https://code.djangoproject.com/ticket/16752#comment:1>

Django

unread,
Sep 3, 2011, 6:50:54 PM9/3/11
to django-...@googlegroups.com
#16752: Multi-db without a 'default' database
-------------------------------------+-------------------------------------
Reporter: jdunck | Owner: nobody
Type: Bug | Status: new
Milestone: | Component: Database layer
Version: 1.3 | (models, ORM)
Resolution: | Severity: Normal
Triage Stage: Design | Keywords:
decision needed | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-------------------------------------+-------------------------------------
Changes (by russellm):

* stage: Unreviewed => Design decision needed


Comment:

The intention at time of design was that there would always need to be a
default database. This was done mostly as a migration aid -- historically,
django.db.connection was your path to the connection; moving to
django.db.conections meant that a lot of older code wouln't work, so the
older alias was retained, using the 'default' alias. I can see how this
could be relaxed so django.db.connection only exists if you actually
define a 'default' alias; I'd need to see a deeper analysis of the
implications of this change to make a definitive call.

The validation problem has been logged previously (#13528) -- it's not an
easy one to fix in a backwards compatible fashion. This may end up being
the biggest reason why the default alias can't be removed entirely.

--
Ticket URL: <https://code.djangoproject.com/ticket/16752#comment:2>

Django

unread,
Sep 16, 2011, 6:40:26 PM9/16/11
to django-...@googlegroups.com
#16752: Multi-db without a 'default' database
-------------------------------------+-------------------------------------
Reporter: jdunck | Owner: nobody
Type: Bug | Status: new
Milestone: | Component: Database layer
Version: 1.3 | (models, ORM)
Resolution: | Severity: Normal
Triage Stage: Accepted | Keywords:
Needs documentation: 0 | Has patch: 0
Patch needs improvement: 0 | Needs tests: 0
UI/UX: 0 | Easy pickings: 0
-------------------------------------+-------------------------------------
Changes (by Alex):

* stage: Design decision needed => Accepted


Comment:

This *should* be sane to accept, and if for any reason it isn't those are
really just sub bugs.

--
Ticket URL: <https://code.djangoproject.com/ticket/16752#comment:3>

Django

unread,
Mar 16, 2017, 3:05:06 PM3/16/17
to django-...@googlegroups.com
#16752: Multi-db without a 'default' database
-------------------------------------+-------------------------------------
Reporter: Jeremy Dunck | Owner: nobody
Type: Bug | Status: new

Component: Database layer | Version: 1.3
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted

Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0

Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Description changed by Anton Samarchyan:

Old description:

> In the [https://docs.djangoproject.com/en/dev/topics/db/multi-db multi-db
> doc] it says:
> {{{
> If you don’t have a default database, you need to be careful to always
> specify the database that you want to use.
> }}}
>
> I have a project where that is exactly the behavior I'd prefer - I want
> to explicitly route every call and have nothing go to the 'default'
> database.
>
> However, when I removed the 'default' key from DATABASES (and hard-coded
> a router to always return a different value), model validation failed.
> This seems to be because it imports
> {{{
> from django.db import connection
> }}}
> then proceeds to validation the schema against that connection (which is,
> in fact, the non-existant 'default'). This fails as soon as an operation
> is called on the connection.
>
> There is a second problem with this -- all model validation occurs
> against the default connection rather than the connection that the model
> will be routed to. That seems like a bug, but I'd like to treat it
> separately.
>
> My intention with this ticket is to establish: do we intend projects to
> work without a 'default' project, as implied by the docs, or is a
> 'default' database always assumed?

New description:

In the [https://docs.djangoproject.com/en/dev/topics/db/multi-db multi-db
doc] it says:
{{{
If you don’t have a default database, you need to be careful to always
specify the database that you want to use.
}}}

I have a project where that is exactly the behavior I'd prefer - I want to
explicitly route every call and have nothing go to the 'default' database.

However, when I removed the 'default' key from DATABASES (and hard-coded a
router to always return a different value), model validation failed. This
seems to be because it imports
{{{
from django.db import connection
}}}
then proceeds to validation the schema against that connection (which is,

in fact, the nonexistent 'default'). This fails as soon as an operation


is called on the connection.

There is a second problem with this -- all model validation occurs against
the default connection rather than the connection that the model will be
routed to. That seems like a bug, but I'd like to treat it separately.

My intention with this ticket is to establish: do we intend projects to
work without a 'default' project, as implied by the docs, or is a
'default' database always assumed?

--

--
Ticket URL: <https://code.djangoproject.com/ticket/16752#comment:4>

Django

unread,
Dec 31, 2023, 12:21:35 PM12/31/23
to django-...@googlegroups.com
#16752: Multi-db without a 'default' database
-------------------------------------+-------------------------------------
Reporter: Jeremy Dunck | Owner: Ryan
| Cheley
Type: Bug | Status: assigned

Component: Database layer | Version: 1.3
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by Ryan Cheley):

* owner: nobody => Ryan Cheley
* status: new => assigned


Comment:

The docs no longer have the statement mentioned in the ticket (it seems to
be have removed in
[https://github.com/django/django/blob/stable/1.5.x/docs/topics/db/multi-
db.txt Django 1.5] but was in
[https://github.com/django/django/blob/stable/1.4.x/docs/topics/db/multi-
db.txt Django 1.4]).

Django 1.4 was the last time this seems to have been in the docs, and
Django 1.4 had and end to extended support in October 1, 2015

Given that, I'm wondering if this can be marked as closed.

--
Ticket URL: <https://code.djangoproject.com/ticket/16752#comment:5>

Django

unread,
Jan 2, 2024, 2:40:39 PM1/2/24
to django-...@googlegroups.com
#16752: Multi-db without a 'default' database
-------------------------------------+-------------------------------------
Reporter: Jeremy Dunck | Owner: Ryan
| Cheley
Type: Bug | Status: assigned
Component: Database layer | Version: 1.3
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Comment (by Natalia Bidart):

Hey Ryan, while I agree that the docs have changed/improved, I think this
ticket is about doing the cleanup to actually remove the need to declare a
`default` database (which should also avoid the need to define a `default`
key, even if empty, in the `DATABASES` dict).

So from my understanding, this ticket is still valid and needs addressing.

--
Ticket URL: <https://code.djangoproject.com/ticket/16752#comment:6>

Django

unread,
Jan 6, 2024, 10:43:26 AM1/6/24
to django-...@googlegroups.com
#16752: Multi-db without a 'default' database
-------------------------------------+-------------------------------------
Reporter: Jeremy Dunck | Owner: Ryan
| Cheley
Type: Bug | Status: assigned
Component: Database layer | Version: 1.3
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Comment (by Ryan Cheley):

Replying to [comment:6 Natalia Bidart]:

Sounds good. I'll get to working on this 😀

> Hey Ryan, while I agree that the docs have changed/improved, I think
this ticket is about doing the cleanup to actually remove the need to
declare a `default` database (which should also avoid the need to define a
`default` key, even if empty, in the `DATABASES` dict).
>
> So from my understanding, this ticket is still valid and needs
addressing.

--
Ticket URL: <https://code.djangoproject.com/ticket/16752#comment:7>

Django

unread,
Jan 6, 2024, 3:47:39 PM1/6/24
to django-...@googlegroups.com
#16752: Multi-db without a 'default' database
-------------------------------------+-------------------------------------
Reporter: Jeremy Dunck | Owner: Ryan
| Cheley
Type: Bug | Status: assigned
Component: Database layer | Version: 1.3
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Comment (by Ryan Cheley):

I've been poking around on this ticket and I'm not sure if the intention
here is to allow a user to specify the name of the default database, that
is allow this code to work (where `core` is ANY name other than `default`)

{{{
DATABASES = {
'core': {
'ENGINE': 'django.db.backends.sqlite3',
'NAME': BASE_DIR / 'db.sqlite3',
}
}
}}}

OR

allow the `DATABASES` setting to have an empty dictionary, that is

{{{
DATABASES = {}
}}}

and if it is set to empty, it assumes what is currently in the
`settings.py` file by default, that is

{{{
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.sqlite3',
'NAME': BASE_DIR / 'db.sqlite3',
}
}
}}}

I think it's the first, but before I get too much further I wanted to add
this comment.

--
Ticket URL: <https://code.djangoproject.com/ticket/16752#comment:8>

Django

unread,
Jan 6, 2024, 6:31:26 PM1/6/24
to django-...@googlegroups.com
#16752: Multi-db without a 'default' database
-------------------------------------+-------------------------------------
Reporter: Jeremy Dunck | Owner: Ryan
| Cheley
Type: Bug | Status: assigned
Component: Database layer | Version: 1.3
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Comment (by Tim Graham):

Option one, although the database shouldn't be treated as the default.
Instead the developer must route each query as explained in the ticket
description. Comment 2 describe the issue and the potential roadblocks
fairly well. I think it will be difficult. Trying to solve #13528 could be
a first step.

--
Ticket URL: <https://code.djangoproject.com/ticket/16752#comment:9>

Django

unread,
Jan 13, 2024, 10:44:21 AM1/13/24
to django-...@googlegroups.com
#16752: Multi-db without a 'default' database
-------------------------------------+-------------------------------------
Reporter: Jeremy Dunck | Owner: (none)
Type: Bug | Status: new

Component: Database layer | Version: 1.3
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by Ryan Cheley):

* owner: Ryan Cheley => (none)
* status: assigned => new


--
Ticket URL: <https://code.djangoproject.com/ticket/16752#comment:10>

Reply all
Reply to author
Forward
0 new messages