--
Ticket URL: <https://code.djangoproject.com/ticket/16752>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
* cc: eng@… (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/16752#comment:1>
* stage: Unreviewed => Design decision needed
Comment:
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/16752#comment:2>
* stage: Design decision needed => Accepted
Comment:
This *should* be sane to accept, and if for any reason it isn't those are
really just sub bugs.
--
Ticket URL: <https://code.djangoproject.com/ticket/16752#comment:3>
Old description:
> In the [https://docs.djangoproject.com/en/dev/topics/db/multi-db 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?
New description:
In the [https://docs.djangoproject.com/en/dev/topics/db/multi-db 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?
--
--
Ticket URL: <https://code.djangoproject.com/ticket/16752#comment:4>
* owner: nobody => Ryan Cheley
* status: new => assigned
Comment:
The docs no longer have the statement mentioned in the ticket (it seems to
be have removed in
[https://github.com/django/django/blob/stable/1.5.x/docs/topics/db/multi-
db.txt Django 1.5] but was in
[https://github.com/django/django/blob/stable/1.4.x/docs/topics/db/multi-
db.txt 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.
--
Ticket URL: <https://code.djangoproject.com/ticket/16752#comment:5>
Comment (by 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.
--
Ticket URL: <https://code.djangoproject.com/ticket/16752#comment:6>
Comment (by Ryan Cheley):
Replying to [comment:6 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.
--
Ticket URL: <https://code.djangoproject.com/ticket/16752#comment:7>
Comment (by 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.
--
Ticket URL: <https://code.djangoproject.com/ticket/16752#comment:8>
Comment (by 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.
--
Ticket URL: <https://code.djangoproject.com/ticket/16752#comment:9>
* owner: Ryan Cheley => (none)
* status: assigned => new
--
Ticket URL: <https://code.djangoproject.com/ticket/16752#comment:10>