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?
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.
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.
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.)
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',
}
}
}
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With