Multi-db without a 'default' database

[Jeremy Dunck]

In the ​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?

[Russell Keith-Magee]

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.

[Alex Gaynor]

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

[Ryan Cheley]

The docs no longer have the statement mentioned in the ticket (it seems to be have removed in ​Django 1.5 but was in ​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.

[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.

[Ryan Cheley]

Replying to 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.

[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.

[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.