Подписывайтесь на рассылку MoscowPython — так быстрее узнавать о датах новых событий сообщества на разных площадках. К сожалению, на Хабре не всегда анонсы публикуются.
С введением в последних версиях тайм-трекинга и особенно Agile очень хочется перейти с Redmine на Youtrack, но конвертора всё нет, уже устали ждать.
Главный недостаток Redmine, это конечно совершенно невразумительные инструменты для анализа оперативной ситуации по проекту, в том числе в плагинах. С остальными недостатками можно как-то мириться.
По-моему самый обычный trade-off: удобство при разработке и поддержке взамен на производительность.
Вцелом, любой мейнстримовый ORM это довольно сложная система, основная цель которой — создание абстракции, которая одинаково хорошо работает с разными бд. И производительность, к сожалению, из-за этого условия часто страдает.
Не совсем, Storage отвечает за то, где хранится результат geoip-поиска: в куках или нигде :)
Не трогать БД в текущей реализации не получится, разве что изменив middleware. Постараюсь в следующей версии подумать над поддержкой mod_geoip.
Вы правы, unsigned int тут хватило бы. Можно также уменьшить размер первичных ключей, бесспорно. Но зачем мелочиться, если вам действительно нужна производительность в первую очередь — не надо использовать SQL-решение :) У нас trade-off производительность меняем на удобство поддержки кастомной географии.
Если в приложении вам достаточно получить строку с названием города или страны — то django-geoip вам, конечно же не нужен. Я уверен, что для массы проектов request.META — более чем достаточно. Но это не наш случай и в заметке я объяснил почему.
Получать геолокацию из окружения не проблема, а как быть с тем, что нам нужна своя, пользовательская география, которую необходимо редактировать администрации сайта? Она хранится в базе обычно, поэтому там же для удобства их связывания хранятся и данные ipgeobase в нашем решении. Да, это не оптимально по производительности, зато позволяет контролировать всю бизнес-логику прямо в django.
Можно заморочиться и выгружать заранее подготовленные данные со своей географией в формате, который поддерживает nginx, чтобы полностью избавиться от завязки на БД. Это решение мне нравится, но пока что игра не стоит свеч для текущих проектов с их нагрузкой.
На каждый запрос никто в базу не лезет, один раз для пользователя, результат геолокации для пользователя кэшируется в куке (уже писал выше). Почему в базе, а не mod_geoip, написано в статье: «потребность в создании своей модели географии, отвечающей задачам бизнес-логики». Мы сделали выбор в пользу удобства создания своих кастомных регионов на основе географии ipgeobase в ущерб скорости и пока не жалеем.
Согласен. Отмечу только, что такая политика в принципе тормозит развитие проекта, потому что каждое нововведение должно быть очень хорошо продумано и взвешено, поэтому не может пройти быстро.
Кое-какие недостатки в архитектуре починить, не ломая обратную совместимость, трудоёмко, либо нереально. Например, то что Django — монолитный фреймворк, не имеющий dependency.
Главный недостаток Redmine, это конечно совершенно невразумительные инструменты для анализа оперативной ситуации по проекту, в том числе в плагинах. С остальными недостатками можно как-то мириться.
Улыбнуло:
Вцелом, любой мейнстримовый ORM это довольно сложная система, основная цель которой — создание абстракции, которая одинаково хорошо работает с разными бд. И производительность, к сожалению, из-за этого условия часто страдает.
Не трогать БД в текущей реализации не получится, разве что изменив middleware. Постараюсь в следующей версии подумать над поддержкой mod_geoip.
Можно заморочиться и выгружать заранее подготовленные данные со своей географией в формате, который поддерживает nginx, чтобы полностью избавиться от завязки на БД. Это решение мне нравится, но пока что игра не стоит свеч для текущих проектов с их нагрузкой.
Кое-какие недостатки в архитектуре починить, не ломая обратную совместимость, трудоёмко, либо нереально. Например, то что Django — монолитный фреймворк, не имеющий dependency.