#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 Changed 9 years ago by
Description: | modified (diff) |
---|
Changed 9 years ago by
Attachment: | migrate_failure.log added |
---|
comment:2 Changed 9 years ago by
Severity: | Normal → Release blocker |
---|---|
Triage Stage: | Unreviewed → Accepted |
comment:3 Changed 9 years ago by
Easy pickings: | set |
---|---|
Owner: | changed from nobody to Marten Kenbeek |
Status: | new → assigned |
comment:4 Changed 9 years ago by
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:5 Changed 9 years ago by
Owner: | changed from Marten Kenbeek to Markus Holtermann |
---|
I'm about to revert the patches for #24075.
comment:6 Changed 9 years ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
comment:7 Changed 9 years ago by
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?
Changed 9 years ago by
Attachment: | migrate_sites_failure.log added |
---|
comment:8 Changed 9 years ago by
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 Changed 9 years ago by
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.