Bardzo podobne do lafagundes question about south migration debug logging, z wyjątkiem tego, że nie używam południa - używam zwykłych migracji Django 1.7. Używam również testowego biegacza django-nose.Jak wyłączyć rejestrowanie debugowania migracji w django?
Kiedy biegnę manage.py test
, nie ma wyjścia rejestrowanie debugowania zrobione:
(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)
----------------------------------------------------------------------
Kiedy uruchomić indywidualny moduł testowy, np ./manage.py test auctions.tests.utils_tests
wyjście rejestrowanie debugowania zawiera wszystkie django.db.backends.schema: DEBUG
linii zaangażowanych w Django migracje:
(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 [])
Który sprawia, że bardzo trudno dostać się z powrotem do rzeczywistej awarii.
Jak mogę wyłączyć to wyjście? Albo na poziomie django, albo nosa?
Dzięki temu konfiguracja LOGGING jest przyjemniejsza. Ale wydaje się, że powinna to być opcja w samym Django? – groovecoder
Skończyłem też na podkręcaniu ustawień 'LOGGING', a konkretnie ustawiłem' handlers' na '['console']' i 'level' na' 'WARNING''. –