СУБД PostgreSQL сейчас вероятно, является самым популярным бакендом для Django. К сожалению, у этой СУБД есть особенность - для построения индексов, она блокирует таблицу, и на время выпололнения индексирования, запись в эту таблицу оказывается недоступной, что приводит к частичной или полной неработоспособности приложения на время выполнения миграции, включающей в себя построение индекса.

Эта особенность создает проблемы с маштабированием приложения при изменении структуры данных - таблицы с большим количеством строк могут индексироваться заметное время - от нескольких минут, до часов. Все это время, приложение ограничено в функциональности, что может быть для него недопустимо.

Как решать эту проблему - описано в данной статье.

Еще одна библиотека строк для Python? Легко - если у вас есть ИИ-помощник.

Рассказываю, что хотел сделать (действительно, ленивые строки), что получилось, как использовал ИИ, с какими проблемами столкнулся, какие выводы для себя сделал.

Попросили рассказать про этот пакет, чем я и займусь.

Пакет Django-Leaflet-Admin-List позволяет добавить карту со всеми географическими объектами на странице в отображение списка в админке Django.

Обнаружил у себя довольно внушительный набор инструментов, разработанных для Django в разное время и для разных целей. Все инструменты под лицензией LGPL, и почти все так или иначе используются в активных проектах. Возможно, какие-то из них окажутся полезны вам, поэтому хочу рассказать о них в этой - кратко, - и возможно, последующих подробных статьях по каким-то из инструментов отдельно.

Привет всем из мира авось-программирования Solidity.

Как я уже писал раньше, при неограниченном использовании маппингов и динамических массивов в Solidity, есть весьма малая, но ненулевая вероятность того, что адреса данных, сохраненных в массивах и маппингах, пересекутся. При этом очевидно, логика контракта будет непредсказуемо нарушена.

Я задался целью по возможности, исследовать, какие сценарии использования маппингов и динамических массивов будут в некотором смысле, наиболее безопасны, то есть гарантировать отсутствие таких коллизий даже теоретически.

Привет всем, хочу рассказать, что у меня получилось, когда я понял, что нам нужен пакет импорта произвольных данных из админки.

Тот, кто подключает Celery к Django, использует как правило, пакет django-celery-results для использования таблицы специальной модели Django в качестве хранилища результатов выполнения задач Celery.

Вероятно, через какое-то время, у вас возникнет желание заменить такую таблицу на что-то другое, например облачное хранилище. Приглашаю под кат всех заинтересованных.

Мне очень не по себе при мысли о том, что до сих пор находятся на первый взгляд вполне адекватные и вменяемые люди моей и смежных профессий - программисты, админы и пр., - сознательно продолжающие работать на реализацию безумных идей все заблокировать, трафик проконтролировать и сломать интернет в попытках его "суверенизации".

... мне (и я надеюсь, нам - профессиональному сообществу) не нужны покаянные речи на публику, этим пусть занимаются те, кому речи являются профессией - политики или журналисты...

Конституция, и далее везде

Приветствую всех, недавно я предложил вам обсудить систему голосования, разработанную Департаментом информационных технологий (ДИТ) г.Москвы.

Обсуждение вышло весьма продуктивным, и по его результатам можно выработать некоторые рекомендации по процедуре голосования. Все, кому это интересно, приглашаются под кат.

Открытые исходники

Недавно в открытый доступ были выложены исходники системы голосования, которая по всей видимости, и будет применяться на электронном голосовании по Конституции в Москве и Нижнем Новгороде.

Данным посланием хабражителям я хотел бы открыть обсуждение того, что получилось у разработчиков, и как нам теперь с этим жить.

Рано или поздно, разработчик на Django встречается с проблемой: как сделать так, чтобы пользователи не могли изменять или удалять, а то и вовсе не видели разные объекты одного и того же типа.

Допустим, ваш проект касается хранения информации о проектах. Разные пользователи входят в разные проекты и не должны видеть информацию о другом проекте. Один и тот же пользователь может входить в несколько проектов и иметь разный статус в разных проектах — где-то он может только просматривать информацию, а в других — править данные. В каком-то проекте пользователь зарегистрирован как персонал проекта, а в другом — только как потребитель его услуг. Уровень доступа соответственно, должен быть совершенно разным.

Этими вопросами занимаются несколько пакетов, мы рассмотрим один из них — Django-Access. Все, кому это интересно, приглашаются под кат.

Привет всем! В связи с ростом блокировок, в том числе необоснованных, сайтов со стороны государства, вашему вниманию предлагается описание идеи, а также прототип настроек сайта, защищенного от блокировок по конкретному пути и доменному имени. Идеи по защите от блокировок:

• со звездочкой
• по адресу IP

будут изложены в других постах. Кому интересна тема, заходите под кат.

Привет всем!

В проектах, основанных на Джанго, часто хочется использовать гибкое управление доступом на уровне записей (объектов), когда разные пользователи имеют, или наоборот, не имеют доступ к отдельным объектам в рамках одной и той же модели.

Я хочу рассказать, какая именно политика доступа к данным требовалась в нашем проекте, почему не нашлось подходящей готовой системы и как появилась новая система управления доступом на уровне записей.

Для наиболее дотошных, далее приведены детали устройства системы, ее внутренней логики и порядка обращения с ней.