Opened 4 years ago

Last modified 4 years ago

#16752 new Bug

Multi-db without a 'default' database

Reported by: jdunck Owned by: nobody
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


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 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?

Change History (3)

comment:1 Changed 4 years ago by jdunck

  • Cc eng@… added

comment:2 Changed 4 years ago by russellm

  • Triage Stage changed from Unreviewed to Design 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 Changed 4 years ago by Alex

  • Triage Stage changed from Design decision needed to Accepted

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

Note: See TracTickets for help on using tickets.
Back to Top