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.