2017-02-22 31 views
1

Я имею в виду, фиксируя все SQL-запросы, сделанные в нашу базу данных PostgreSQL для каждого запроса с использованием промежуточного программного типа Snippet 1 или Snippet 2Это хорошая идея для регистрации всех запросов sql в производстве django?

Будет ли это влиять на производительность приложения? Обычное журналирование Postgres не работает для меня, потому что наряду с SQL-запросом я также должен хранить некоторую дополнительную информацию.

Я попытался выполнить регистрацию всех запросов sql, используя ведение журнала базы данных, но, к сожалению, это не работает, когда DEBUG = False в файле настроек.

+1

Мы не знаем вашу установку, поэтому мы не можем сказать, что произойдет. Конечно, это не ускорит приложение. ;-) –

+0

@ KrzysztofSzularz, но я хочу знать, это хорошая идея? Выполнять ведение базы данных на уровне django? Это хорошая практика? –

+2

Хорошая практика заключается в том, чтобы не хранить запросы БД в журналах в процессе производства. Это может привести к утечке учетных данных/конфиденциальной информации. Также @ KrzysztofSzularz прав. Это замедлит приложение. Также будут иметь ненужные журналы, вы можете пропустить важные журналы между ними – ruddra

ответ

2

У вас может быть пользовательский журнал, определяющий Вход в настройку.py , пожалуйста, прочитайте этот документ.

можно протоколирования при отладке = ложь с этим документ:

logging doc добавить этот код setting.py:

LOGGING = { 
'version': 1, 
'disable_existing_loggers': False, 
'handlers': { 
    'file': { 
     'level': 'DEBUG', 
     'class': 'logging.FileHandler', 
     'filename': '/path/to/debug.log', 
    }, 

}, 
'loggers': { 
    'django.db.backends': { 
     'handlers': ['file'], 
     'level': 'DEBUG', 
    }, 
}} 

в две ссылки, которые вы положили выше snippet2 говорит, что работает только при отладке = правда и snippet1 в строке 35 есть условие, как это:

if len(connection.queries) > 0 and settings.DEBUG: 
    .... 

что шо ws работает в debug = true

Надеюсь, это поможет.