Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

How do I disable django migration debug logging?

Very similar to lafagundes question about south migration debug logging, except I'm not using south - I'm using plain Django 1.7 migrations. I'm also using django-nose test runner.

When I run manage.py test, there is no debug logging output captured:

(codesy)lcrouch:codesy lcrouch$ ./manage.py test
nosetests --verbosity=1
Creating test database for alias 'default'...
......E...............................
======================================================================
ERROR: test_return_state (auctions.tests.utils_tests.IssueStateTest)
----------------------------------------------------------------------

When I run an individual test module, e.g., ./manage.py test auctions.tests.utils_tests, the debug logging output includes all of the django.db.backends.schema: DEBUG lines involved in the Django migrations:

(codesy)lcrouch:codesy lcrouch$ ./manage.py test auctions.tests.utils_tests
nosetests auctions.tests.utils_tests --verbosity=1
Creating test database for alias 'default'...
E
======================================================================
ERROR: test_return_state (auctions.tests.utils_tests.IssueStateTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/lcrouch/code/codesy/codesy/auctions/tests/utils_tests.py", line 13, in test_return_state
    fake_gh_client = fudge.Fake(github_client).returns_fake().provides('get_repo').returns_fake().provides('get_issue').returns_fake().has_attr(state='open')
  File "/Users/lcrouch/python/codesy/lib/python2.7/site-packages/fudge/__init__.py", line 1133, in returns_fake
    exp = self._get_current_call()
  File "/Users/lcrouch/python/codesy/lib/python2.7/site-packages/fudge/__init__.py", line 765, in _get_current_call
    "Call to a method that expects a predefined call but no such call exists.  "
FakeDeclarationError: Call to a method that expects a predefined call but no such call exists.  Maybe you forgot expects('method') or provides('method') ?
-------------------- >> begin captured logging << --------------------
django.db.backends.schema: DEBUG: CREATE TABLE "django_migrations" ("id" integer NOT NULL PRIMARY KEY AUTOINCREMENT, "app" varchar(255) NOT NULL, "name" varchar(255) NOT NULL, "applied" datetime NOT NULL); (params [])
django.db.backends.schema: DEBUG: CREATE TABLE "django_content_type" ("id" integer NOT NULL PRIMARY KEY AUTOINCREMENT, "name" varchar(100) NOT NULL, "app_label" varchar(100) NOT NULL, "model" varchar(100) NOT NULL); (params [])
django.db.backends.schema: DEBUG: CREATE TABLE "django_content_type__new" ("id" integer NOT NULL PRIMARY KEY AUTOINCREMENT, "name" varchar(100) NOT NULL, "app_label" varchar(100) NOT NULL, "model" varchar(100) NOT NULL, UNIQUE ("app_label", "model")); (params [])
...
django.db.backends.schema: DEBUG: DROP TABLE "socialaccount_socialapp"; (params [])
django.db.backends.schema: DEBUG: ALTER TABLE "socialaccount_socialapp__new" RENAME TO "socialaccount_socialapp"; (params [])

Which makes it really hard to get back up to the actual failure.

How can I disable this output? Either at the django or nose level?

like image 622
groovecoder Avatar asked Aug 22 '15 17:08

groovecoder


People also ask

How do I fix migration issues in Django?

you can either: temporarily remove your migration, execute python manage.py migrate, add again your migration and re-execute python manage.py migrate. Use this case if the migrations refer to different models and you want different migration files for each one of them.

What happens if I delete Django migrations?

Deleting migration files means losing your history. This historical info is recorded in the django_migrations table in your database. if you delete migration files, you will get dependency errors. So Don't try to lose your history by deleting your migration files.

Is Django migration necessary?

No, you don't need to use migrations. (Also, it may be relevant to note that you can use raw SQL, but Django will still set up some things for you so you can use its ORM, even with legacy databases. But migrations are not one of these things it does for you.)


2 Answers

If you don't mind disabling migrations in testing, you can do so by adding the following to your settings.py:

TESTING = 'test' in sys.argv

if TESTING:
    class DisableMigrations(object):
        def __contains__(self, item):
            return True

        def __getitem__(self, item):
            return "notmigrations"

    MIGRATION_MODULES = DisableMigrations() 

This will just create the database in one go, rather than stepping through each migration.

If you want to keep migrations running in tests, you might be able to remove the messages by updating the logging setting.

TESTING = 'test' in sys.argv

if TESTING:
    LOGGING = {
        'version': 1,
        'handlers': {
            'file': {
                'level': 'DEBUG',
                'class': 'logging.FileHandler',
                'filename': '/tmp/codesy-debug.log',
            },
        },
        'loggers': {
            'django.db.backends.schema': {
                'handlers': ['file'],
                'propagate': True,
                'level': 'INFO',
            },
            '': {
                'handlers': ['file'],
                'level': 'DEBUG',
            }
        }
    }
like image 114
rchrd2 Avatar answered Oct 31 '22 09:10

rchrd2


To quickly remove the logging messages, you can run with:

./manage.py test --nologcapture

The messages are being captured by the nose logcapture plugin, which has additional options for fine tuning. However, django-nose has an old issue that may prevent you from using many of those from the command line. It's scheduled for milestone v1.4.2, but that's a month overdue. You may be able to work around those with .noserc or nose.cfg file - see nose docs for format.

like image 41
jwhitlock Avatar answered Oct 31 '22 11:10

jwhitlock