Если используется threading.local, то лучше сразу ложить туда request. Но стоит помнить, что на сервере с gevent workers необходим monkey patch пакета threading. Иначе можно нарваться на забавные баги, очень похожие на черную магию)
Сигналы, как и любая другая каскадная логика, могут резко усложнить жизнь при росте сложности проекта. Например сигналы, зависящие от request, превращаются в головную боль при восстановлении объектов из fixtures, работе с консоли и т.д. А если человек еще и не подумал о подключении к нескольким БД (аргумент using), то повреждения данных и танцы с транзакциями на несколько connections обеспечены.
Хранить и оперировать данными - разные вещи. Можно построить кластер на десяток террабайт, но расчет в нем среднее арифметическое на какой-нибудь гигантской таблице/колонке, займет минуты, если не часы. Гарантий по времени исполнения вам никто не давал.
Главное понять, высчитывать статистику "на лету" - плохая не эффективная практика. Нет смысла держать миллионы записей в БД для их постоянного GROUP BY, если только база не поддерживает материализованные представления (хак, достойный отдельного разговора).
Из моего опыта, должно быть хранилище для логов "как есть", медленное, но под большие объемы. Обычные файлы с архивами на сетевом диске для этого хорошо подходят. Должен быть вычислительный комплекс, можно на map-reduce, который не спеша расчитывает аналитику по логам. При этом комплекс может всегда начать считать что-то новое с самой первой записи архива. Результаты аналитики (коэфициенты линейной регрессии; sum/max/min/avg по часу/дню/неделе/месяце; корреляционные таблицы и т.д.) сливаются в любую БД. Очевидно, что результаты аналитики будут во много раз меньше исходных данных. Далее, по аналитике рисуем красивые графики.
Минус подхода - отсутствие произвольных запросов. Но как показала практика, люди не любят и путаются в произвольных запросах к статистике. Человек хочет видеть динамику роста продаж на графике с резолюцией в заранее известные интервалы (день, неделя и т.д.), а также ее корреляцию с днем недели и т.п. Вы всегда можете дополнить ваш вычислительный комплекс новым view на данные и расчитать все с первых записей архива.
Тогда все просто, добавляете к своему админу метод save_model(). По умолчанию это просто obj.save(), но вы перед этим можете проводить с объектом любые манипуляции. В документации по ссылке сразу приводится решение вашей проблемы, присвоение текущего пользователя.
Админка это тоже view. Если вы используете django.contrib.admin (иными словами admin.py в вашем приложении), то у вашего ModelAdmin есть методы add_view, change_view etc. Все они принимают request, из которого есть доступ к текущему пользователю request.user Вы можете переопределить эти методы или инициализировать форму вместе с request, либо передать себе request в save_object. Вариантов масса. Я так понимаю, вы скрыли поле author, поэтому оно не появляется в форме с большим списком пользователей?
Кластер из 3 машин, PB, клиент и приложение на питоне. Бинарные документы стоит хранить в кластере ради надежности и доступности. К примеру магазин (bodyenfitshop.nl), покупка создает снимок всех объектов (продукты, скидки, часть правил логики и т.д.) на тот момент в JSON. Снимок позволяет просматривать фактуру и пересчитывать статистику в любое время позже, не переживая, что один из десятков связанных объектов мог измениться (классическая проблема молодых магазинов). Снимок сливается в Riak. В итоге он надежно доступен (репликация) и доступен с любого из app. серверов практически мгновенно. Можно, конечно, сливать все на диск и синхронизировать rsync'ом между машинами (!задержка), или примонтировать общий диск (!задержка, не надежно), но появляется проблема с блокировками (на NFS вообще труба), IO, медленной работой ОС с директориями в сотни тысяч файлов и т.д. Короче, Riak.
Riak хороший key-value store. Использовал его для хранения пользовательских картинок и документов - хорошо он бинарные данные хранит и отдает. Он больше ориентирован на надежность с его шустрой репликацией и кворумом. Но на запись он все таки не самый быстрый (вполне ожидаемо), проверил на своем опыте. Также как и любой key-value store нет явной последовательности ключей (лог, FIFO). В общем писать большие бинарные документы не шибко часто с высокой надежностью и быстрым доступом на чтение - Riak хорош. В качестве лога, не очень.
Кстати, MySQL с его in-memory движком тоже супер быстрая вещь, если нужна вся мощь SQL, вместо простого доступа по ключу. Поэтому хорошо знать о tarantool, но не вижу чем он лучше проверенных решений (не вижу его нишы).
Замечательная вещь для разного рода кешей, счетчиков и прочего. Но оно in-memory для быстрого доступа. Мне же требуется быстрая запись, а чтение временем не ограничено. Если мне нужен in-memory быстрая БД, то как обычно Memcached (если это кеш) -> Redis (если persistent кеш) -> MongoDB (если persistent кеш с (geo)индексами).
Можно, но это не входит в задачу. Одно событие живет не дольше, чем будет прочитано аггрегатором. Постройка индекса это не нужные накладные расходы, а сам индекс никогда не будет использоваться. Само сообщение это немного данных в JSON и не предназначено для чтения человеком. Но возьму logstash на вооружение, хороший фильтр логов. Спасибо.
Не плохо, но задача несколько проще. Не требуется хранить отдельные записи или искать в них, используются только результаты процессов-аггрегаторов. С другой стороны, необходимо обеспечить ~нулевое время задержки на запись события. Собственно искомый сервис это быстрое на запись временное хранилище для событий.
Можно, но хотелось бы готовое решение. Главная проблема - это обеспечить одновременную запись с большого множества процессов без блокировок. Может приходить 50к сообщений в секунду, в пиковые моменты много больше. При этом сами сообщения не надо выстраивать в каком либо порядке и редкие потери не страшны. Главное очень краткое О(1) время записи.
Тогда можно унаследовать User (совместимо со сторонними приложениями) или вообще сделать собственный и определить свой AUTHENTICATION_BACKENDS. В request.user будет лежать то, что вы хотите.
Даже если используются профили стандартным способом, то полезно сделать свой authentication-backend, который выберет профиль.select_related('user') одним запросом (это быстрей дла 99% обыкновенных сайтов).
Опять же, не стоит слепо следовать одному правилу. Иногда для простоты допускается «некорректное» состояние объекта, для последующей более общей проверки. К примеру некоторая форма на странице или в окне пишет пользовательские изменения сразу в ваш объект (модель). Перед записью мы проверяем obj.validate(); если прошли проверку, сохранили изменения. Такой подход очень сильно упрощает форму и работу с вашей моделью (меньше танцев вокруг try/catch и временных значений вне модели).
Если объекту недопустимо пребывать в «некорректном» состоянии и вообще он immutable после создания, то создаем его через builder. Builder'у позволительно временно принимать некорректные значения, если само понятие корректности зависит от других свойств (к примеру e-mail принимаем только если флаг has_email установлен). Тогда валидация происходит в самом конце, когда строим финальный объект.
В обоих случаях выше не генерим исключение в setter'e. Все по задаче, без догм и бездумных рецептов.
Moodle – аналог неудачного Blackboard. Это не плохой инструмент хранить факты, например оценки, лабораторные работы или просто учебный материал в документах (аттачах). Но это, на мой взгляд, не система, позволяющая создавать курсы/учебный материал, по которому можно дистанционно обучаться (ну кроме как выкачал PDF, прочел). Мало того, сложилось впечатление, что Blackboard/Moodle — это пример как не надо подавать учебный материал детям до 16 лет. С интересом узнаю о плагинах, которые исправляют ситуацию. Спасибо.
Дневник — интересная социальная сеть, призванная по моему мнению, опубликовать в сети процессы внутри школы. Но сайт не направлен на сетевое обучение. Медиатека — это просто куча не связанных отдельных фактов. Может быть это не плохо для энциклопедии, но для учебы не пойдет. Собственная библиотека - это идея для последующего развития проекта. Есть где почерпнуть идеи для социальной сети среди учителей/учеников, спасибо.
Ой, извиняюсь за питон. В любом случае подход с настоящим рендером будет лучше в плане графики. wkhtmltopdf может работать как консольная утилита, вызываемая из php.
> В силу организационных причин, сменить http-сервер нельзя.
Никто не заметит, что апач вдруг стал работать на другом порту. Скрипты будут получать от nginx все метаданные. С одной лишь разницей, что апачу не придется отдавать статику, но и это можно оставить (что не очень эффективно) если скрипты чего умного с ней делают в run-time.
И для админа апача ничего кроме порта не измениться. Проблем быть не должно.
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
