Opened 17 months ago

Closed 17 months ago

Last modified 17 months ago

#21211 closed Cleanup/optimization (wontfix)

DEFAULT_DB_ALIAS in settings

Reported by: martyn.clement@… Owned by: nobody
Component: Database layer (models, ORM) Version: 1.5
Severity: Normal Keywords: database, settings, DEFAULT_DB_ALIAS
Cc: martyn.clement@… Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

Hi,

I have a usecase that requires the django.db.utils.DEFAULT_DB_ALIAS to be in the settings.
It doesn't seem to require a lot of work and I don't see any reason why this could not be in a setting.

Change History (6)

comment:1 Changed 17 months ago by timo

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

What's the use case?

comment:2 Changed 17 months ago by anonymous

My project is splitting in 2 different database but has to use all the same basecode.
The code has to know on which database it is running and has also to know which database is the other one so that I can retrieve some information with Model.objects.using(...) .

So I made 2 projects (by project I mean, 2 folders containing manage.py, individual settings etc...).
There is no idea of a "default". I use a custom router to tell django on which database it has to run.

But the problem come when I run django commands (for ex: .manage.py shell) or when I have to use the django.db.connection.
I thought the router had a global effect, but it affects only the ORM.

In my settings, if I could set the DEFAULT_DB_ALIAS to the concerned database, it should be ok.

Moreover, I don't see why this variable has to be immutable.
By default, it's "default" but user can set it if needed.

comment:3 Changed 17 months ago by Martyn CLEMENT <martyn.clement@…>

Sorry, I forgot to authenticate.

comment:4 Changed 17 months ago by timo

  • Resolution set to wontfix
  • Status changed from new to closed

I haven't used multi-db extensively so I may be off, but the multi DB docs say: "Django requires that a default database entry be defined, but the parameters dictionary can be left blank if it will not be used." Why not use this approach and have each of your databases explicitly defined? You could have 'default' point to nothing or whatever database each machine is using as the "primary" if that makes sense.

In any case, the barrier to adding new settings in Django is high and I'm pretty skeptical of this change meeting that criteria. You'll need to write to the django-developers and explain your rationale. As an aside, have you tried making the changes in Django for this? I can't say for sure, but I feel like there will probably be unexpected issues.

comment:5 Changed 17 months ago by Martyn CLEMENT <martyn.clement@…>

OK, thanks for your reply.

Maybe this ticket will be turned onto a bug because I did what the doc says : I have an empty "default" dictionary and I can reproduce the bug by doing :

from django.db import connection
cursor = connection.cursor()

>> ImproperlyConfigured: settings.DATABASES is improperly configured. Please supply the ENGINE value. Check settings documentation for more details.

This error is raised because the "default" dictionary is empty.
I also saw this error happening on some M2M relations (when calling MyModel.m2m.all())

comment:6 Changed 17 months ago by timo

If you don't specify a database to use, the default is used. If it's empty, I'd expect that error.

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