Собрали в одном месте самые важные ссылки
и сделали Тренажер IT-инцидентов для DevOps/SRE
Обзор Django caching framework
Рано или поздно, разработчик на Django встречается с проблемой: как сделать так, чтобы пользователи не могли изменять или удалять, а то и вовсе не видели разных объектов одного и того же типа.
Допустим, ваш проект касается хранения информации о проектах. Разные пользователи входят в разные проекты и не должны видеть информацию о другом проекте. Один и тот же пользователь может входить в несколько проектов и иметь разный статус в разных проектах — где-то он может только просматривать информацию, а в других — править данные. В каком-то проекте пользователь зарегистрирован как персонал проекта, а в другом — только как потребитель его услуг. Уровень доступа соответственно, должен быть совершенно разным.
Этими вопросами занимаются несколько пакетов, мы рассмотрим один из них — Django-Access. Все, кому это интересно, приглашаются под кат.
Заметка о переопределение пользовательской модели в Django, а также описание некоторых нюансов, которые нужно учитывать при разработке третьесторонних библиотек для Django, которые используют пользовательскую модель.
Небольшая заметка о том, как поправить queryset форме администрирования admin.ModelAdmin или UserAdmin . Собственно разницы никакой, поскольку форма UserAdmin наследована от admin.ModelAdmin . Но тем не менее покажу на примере UserAdmin
Перевод статьи: Leonardo Giordani – Multiple inheritance and mixin classes in Python
Недавно я пересмотрел три своих старых статьи о представлениях на основе классов Django (class-based views), которые написал для своего блога, обновив их до Django 3.0 (вы можете найти их здесь), и еще раз обнаружил, большое количество кода использующего классы mixin для улучшения повторного использования кода. По своему опыту я понял, что миксины не очень популярны в Python, поэтому решил изучить их лучше, тем самым освежив свои знания теории ООП.
При написании приложений на Python, для работы с базами данных часто используются объектно-реляционные мапперы (ORM). Примерами ORM являются SQLALchemy, PonyORM и объектно-реляционный маппер, входящий в состав Django. При выборе ORM довольно важную роль играет её производительность.
Оригинальная статья: PAWEŁ FERTYK – Getting started with Django middleware
Django поставляется с множеством полезных функций. Одним из них является механизм middleware (переводится как промежуточное программное обеспечение). В этом посте я кратко объясню, как работает middleware и как начать писать свой собственный.
Исходный код, включенный в этот пост, доступен на GitHub.
Python, хоть и мощный, но всего лишь инструмент, который позволяет писать выразительный самодокументируемый код, но не гарантирует этого, как не гарантирует этого и соблюдение PEP8. Когда наш, казалось бы, простой интернет-магазин на Django начинает приносить деньги и, как следствие, накачиваться фичами, в один прекрасный момент мы понимаем, что он не такой уж и простой, а внесение даже элементарных изменений требует все больших и больших усилий, а главное, что эта тенденция все нарастает. Что случилось, и когда все пошло не так?
Динамическое создание моделей или полей к уже существующей модели в ORM Django редко встречаемая задача, но иногда специфика бизнеса требует ее реализации. К примеру может возникнуть необходимость получение данных из внешней БД и при этом сами данные могут иметь либо очень большее количество полей (более 100), либо иметь постоянно меняющиеся поля. Но вы должны быть осторожны, если пойдете по этому пути, особенно если ваши модели настроены на изменение во время выполнения. В этой статье я рассмотрю ряд вопросов, которые следует учитывать при создание динамических моделей.