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 )
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 , 13 years ago
Cc: | added |
---|
comment:2 by , 13 years ago
Triage Stage: | Unreviewed → Design decision needed |
---|
comment:3 by , 13 years ago
Triage Stage: | Design decision needed → Accepted |
---|
This *should* be sane to accept, and if for any reason it isn't those are really just sub bugs.
comment:4 by , 8 years ago
Description: | modified (diff) |
---|
comment:5 by , 11 months ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
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.
follow-up: 7 comment:6 by , 11 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.
comment:7 by , 11 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 adefault
key, even if empty, in theDATABASES
dict).
So from my understanding, this ticket is still valid and needs addressing.
comment:8 by , 11 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 , 11 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 , 10 months ago
Owner: | removed |
---|---|
Status: | assigned → new |
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.