#24298 closed Bug (fixed)
post-migrate handlers fail when DATABASES['default'] = {}
Reported by: | Thomas Recouvreux | Owned by: | Markus Holtermann |
---|---|---|---|
Component: | Migrations | Version: | 1.7 |
Severity: | Release blocker | Keywords: | migrate post_migrate |
Cc: | Triage Stage: | Accepted | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | yes | UI/UX: | no |
Description (last modified by )
On Django 1.7.4 the management command migrate --database=xxx
fails when DATABASES['default'] = {}
with django.core.exceptions.ImproperlyConfigured: settings.DATABASES is improperly configured. Please supply the ENGINE value. Check settings documentation for more details.
.
On Django 1.7.3 it works fine.
To reproduct the problem:
- Create a new project
- Edit the settings.py this way:
DATABASES = { 'default': {}, 'mysite': { 'ENGINE': 'django.db.backends.sqlite3', 'NAME': os.path.join(BASE_DIR, 'db_mysite.sqlite3'), } }
- Run
python manage.py migrate --database=mysite
Problem:
It seems Django tries to access the default connection. I found django.db.migrations.loader.is_latest_migration_applied
uses the default connection.
I am attaching an output log of the command.
Here is a sample project to reproduce the behaviour: https://github.com/trecouvr/test_dj_migrate_174.
Attachments (2)
Change History (11)
comment:1 by , 10 years ago
Description: | modified (diff) |
---|
by , 10 years ago
Attachment: | migrate_failure.log added |
---|
comment:2 by , 10 years ago
Severity: | Normal → Release blocker |
---|---|
Triage Stage: | Unreviewed → Accepted |
comment:3 by , 10 years ago
Easy pickings: | set |
---|---|
Owner: | changed from | to
Status: | new → assigned |
comment:4 by , 10 years ago
Patch: https://github.com/knbk/django/compare/ticket_24298
I'm not too sure on the tests, I'd like some feedback on that before I create a pull request.
comment:6 by , 10 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
comment:7 by , 10 years ago
I think there is an additional failure scenario in the Sites
application. I haven't had the chance to track down the source of the defect in Sites
, in the event that I do, should I reopen this ticket or submit a new ticket?
by , 10 years ago
Attachment: | migrate_sites_failure.log added |
---|
comment:8 by , 10 years ago
Thank you for the quick updates. Following the report of awol I updated my test project and added a log file. I found the problem might come from the django.contrib.sites.management.create_default_site
function which calls Site.objects.exists
without propagating the using
parameter. I dont know either if I should create a new ticket or not.
comment:9 by , 10 years ago
Although it's a similar issue (missing use of using
), it is still due to another bug. It should be Site.objects.using(using).exists()
in line 20.
Please open a separate issue for that.
Seems easy enough, only 3 occurrences in the whole code-base.