Opened 13 years ago

Last modified 10 months ago

#16752 new Bug

Multi-db without a 'default' database

Reported by: Jeremy Dunck Owned by:
Component: Database layer (models, ORM) Version: 1.3
Severity: Normal Keywords:
Cc: eng@… Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description (last modified by Anton Samarchyan)

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?

Change History (10)

comment:1 by Jeremy Dunck, 13 years ago

Cc: eng@… added

comment:2 by Russell Keith-Magee, 13 years ago

Triage Stage: UnreviewedDesign decision needed

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.

comment:3 by Alex Gaynor, 13 years ago

Triage Stage: Design decision neededAccepted

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

comment:4 by Anton Samarchyan, 8 years ago

Description: modified (diff)

comment:5 by Ryan Cheley, 10 months ago

Owner: changed from nobody to Ryan Cheley
Status: newassigned

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.

comment:6 by Natalia Bidart, 10 months ago

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.

in reply to:  6 comment:7 by Ryan Cheley, 10 months ago

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.

comment:8 by Ryan Cheley, 10 months ago

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.

comment:9 by Tim Graham, 10 months ago

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.

comment:10 by Ryan Cheley, 10 months ago

Owner: Ryan Cheley removed
Status: assignednew
Note: See TracTickets for help on using tickets.
Back to Top