Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#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 Thomas Recouvreux)

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:

  1. Create a new project
  2. Edit the settings.py this way:
DATABASES = {
    'default': {},
    'mysite': {
        'ENGINE': 'django.db.backends.sqlite3',
        'NAME': os.path.join(BASE_DIR, 'db_mysite.sqlite3'),
    }
}
  1. 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)

migrate_failure.log (3.2 KB) - added by Thomas Recouvreux 5 years ago.
migrate_sites_failure.log (5.5 KB) - added by Thomas Recouvreux 5 years ago.

Download all attachments as: .zip

Change History (11)

comment:1 Changed 5 years ago by Thomas Recouvreux

Description: modified (diff)

Changed 5 years ago by Thomas Recouvreux

Attachment: migrate_failure.log added

comment:2 Changed 5 years ago by Tim Graham

Severity: NormalRelease blocker
Triage Stage: UnreviewedAccepted

comment:3 Changed 5 years ago by Marten Kenbeek

Easy pickings: set
Owner: changed from nobody to Marten Kenbeek
Status: newassigned

Seems easy enough, only 3 occurrences in the whole code-base.

comment:4 Changed 5 years ago by Marten Kenbeek

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 5 years ago by Markus Holtermann

Owner: changed from Marten Kenbeek to Markus Holtermann

I'm about to revert the patches for #24075.

comment:6 Changed 5 years ago by Markus Holtermann

Resolution: fixed
Status: assignedclosed

comment:7 Changed 5 years ago by awol

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 5 years ago by Thomas Recouvreux

Attachment: migrate_sites_failure.log added

comment:8 Changed 5 years ago by Thomas Recouvreux

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 5 years ago by Markus Holtermann

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.

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