Django проект логов и пространство имен приложений - PullRequest
Новая
       6

Django проект логов и пространство имен приложений

0 голосов
/ 18 января 2012

У меня проблема с регистрацией в Django. Кстати, ответы на этот вопрос помогут мне уточнить, как работают пространства имен Django.

Вот структура моего проекта: 

MyProject:
    -App1:
         ....
         views.py
    -App2:
         ....
    urls.py
    settings.py

Мне нравится регистрировать все сообщения в одном файле. Затем я настроил в settings.py следующий логгер: 

LOGGING = {
    'version': 1,
    'disable_existing_loggers': True,
    'formatters': {
            'verbose': {
                    #'format': '%(levelname)-8s %(remote_addr)-15s %(path_info)s %(asctime)s %(name)-20s %(funcName)-15s %(message)s'
                    'format': '%(levelname)-8s %(asctime)s %(name)-20s %(funcName)-15s %(message)s'
                    },
            },
    'handlers': {
            'normal': {
            'level': 'DEBUG',
            'class': 'logging.FileHandler',
            'formatter': 'verbose',
            'filename': os.path.join('C:/dev/Instantaneus/Instantaneus/html/static', 'log', 'normal.log')
        },
            'console': {
            'level': 'DEBUG',
            'class': 'logging.StreamHandler',
            'formatter': 'verbose',
            },
        },
    'loggers': {
        'MyProject': {
                'handlers': ['normal','console'],
                'level': 'DEBUG',
                #'filters': ['request'],
                'propagate': True,
                },
            }
       }

In urls.py:

from MyProject.App1.views import EvenementDetailView,
....
url(r'App1/(?P<pk>\d+)/$', login_required(EvenementDetailView.as_view(model=Evenement)), name='evenement_details'),

и в App1 / views.py: 

from django.views.generic import DetailView
import logging
logger = logging.getLogger(__name__)

....

class EvenementDetailView(DetailView):
    print __name__
    model=Evenement
    ....
    logger.debug('blabla')

В браузере, когда я звоню http://localhost/App1/3, в консоли появляется следующее: 

DEBUG    2012-01-18 14:59:04,503 Myproject.evenements.views EvenementDetailView blabla
MyProject.evenements.views
evenements.views

Тогда мой вопрос: почему код print __name__ выполняется дважды, и самое важное, почему выходные данные не совпадают?

Я предполагаю, что журнал DEBUG появляется только один раз, потому что evenement.views не может распространяться на MyProject, потому что в этом случае root равен evenements

Есть идеи?

Решение, не с подробным объяснением, но оно работает:

В моем urls.py у меня была строка url(r'App1/(?P<pk>\d+)/activate/$', 'app1.views.activate'), где 'activ' - это функция в App1 / views.py. Я изменил 'App1.views.activate' в 'MyProject.app1.views.activate', и он работает нормально. У меня только одна строка в консоли для print __name__. Я думаю, что у меня есть только одна строка из-за 'disable_existing_loggers': True, но я не могу объяснить, что это решение заставило мои views.py анализировать только один раз, а не два раза раньше. Чтобы быть уверенным в этом, я добавил print "blabla" в начале файла. В первом случае он печатается два раза, а во втором - только один раз.

1 Ответ

1 голос
/ 18 января 2012

Справедливое предупреждение: я не уверен, что это правильно, и я основываю кое-что из этого на материалах, которые я давно читал, но не могу найти в Google сейчас.

Что вывы видите побочный эффект того, как работает механизм импорта python.Когда модуль импортируется, он помещается в sys.modules, однако, когда есть возможность импортировать модуль по двум различным пунктирным путям (в данном случае, с MyProject или без него), его можно импортировать дважды, один раз под каждым __name__.

Основное исправление - убедиться, что MyProject не включено sys.path - должен быть каталог , содержащий MyProject, но не сам MyProject.Вы можете убедиться, что это сделано, запустив manage.py shell и убедившись, что import evenements не удалось.В manage.py есть некоторые внутренности Django, которые могут сделать это трудным, но в последний раз я столкнулся с этим около 1.0 или 1.1, так что, возможно, это было исправлено.

Там есть углубленное обсуждениездесь:

http://blog.dscpl.com.au/2010/03/improved-wsgi-script-for-use-with.html

Это длинная статья, ищите "два разных имени".

...