Comments 10
https://github.com/just-work/django-admin-countless Админка без count.
эээ ребят, ModelAdmin.show_full_result_count
New in Django 1.8 (April 1, 2015)
Этого недостаточно, к сожалению.
show_full_result_count скрывает только общее число результатов из отфильтрованных. Что делать, если даже с учетом фильтров остаются миллионы записей, документация Django умалчивает. В результате - запрос COUNT с учетом фильтра, текст вверху вида "2575 results (Show all)" и пагинатор на 100500 страниц после списка. Хотя нет. В результате - 504.
недавно делал два доклада тут и тут, как раз про админку Django.
Стандартный select / raw_id_fields в принципе то да, для новой джанго завезли уже select2 из коробки. Работает отлично. Правда, ломает grapelli, если у кого стоял.
Фраза "выгружайте все необходимое одним запросом несовместима" с prefetch_related. Данные полей prefetch_related догружаются после отдельными запросами. Я бы в статье добавил активное использование "only", вот эта штука здорово заставляет подумать и получить только то, что надо.
Стоит убедится, что нигде не указываете ordering. Увы, даже если нигде ничего не указано, джанго приклеит .order_by(model._meta.pk.name)
SHOW TABLE STATUS LIKE table_name, не работает в случае предварительных фильтров. В случае мультитеннантности на разнобазовых запросах, придется переделывать запрос.
25 раз по мало < 1 раз много. Согласен, другой вопрос, если данные второй таблицы точно присутствуют, то можно переопределить тип джоина на INNER JOIN. для больших таблиц может быть быстрее.
перегрузить поиск. Прям да. В одном из моих проектов только этим и спасались. Только конечно все намного глобальнее. Сначала собирали ID по моделям из ModelAdmin.search_fields и потом filter(linked_model__id_in=id_set).
продумай заранее индексы. Спорно, поскольку заранее "соломку" не всегда успеешь подстелить. Про индексы в таблице с 62mln строк была Альбина Альмухаметова на pycon 2021 с докладом "Оптимизация i-запросов в Django+Postgres". От себя скажу, что один раз в моей жизни для убыстрения запросов индекс пришлось удалять.
сложные фильтры в админке. Бывает. Бизнесу не прикажешь работать проще. Но посмотреть на запросы стоит, иногда можно сформировать зпрос проще, чем это делает родной ORM
Работает только с недавнего момента. В ранних версиях Django возвращает EmptyQuerySet вместо type(super().get_queryset(request)). Если класс был переопределен, то все ломалось.
Не знаешь зачем тебе данные, не показывай. Понимаю что речь немного о другом, но сюда подходит текст про only. Этот метод точно заставить подумать "нужны ли мне все данные которые я получаю из базы".
Группируй модели в группы по смыслу. Вместо предложенной сомнительной батарейки можно использовать смысловое группирование по множественным SiteAdmins. Я в своих проектах использую именно эту возможность Django.
Мой вывод, что Django Contrib Admin + прямые руки помогут и графики показать и запросы сложные сделать и лишние батарейки деинсталлировать. Для красоты мне не хватает анимаций и переходов "из коробки", это пришлось допиливать другими средствами.
Спасибо @WarmongeR. Жаль я не прочел это в 2017. Пришлось разбираться самому.
Отличное дополнение! А где можно почитать про множественные SiteAdmins?
Можно посмотреть меня на видео с PyCon второй день, первое выступление. Вроде видео уже есть. Или подождать когда я выложу статью. Увы в документации минимум.
привет, есть видео моего доклада https://www.youtube.com/watch?v=8v2uaeV8MZo, первая половина про множественные SiteAdmins
один раз в моей жизни для убыстрения запросов индекс пришлось удалять.
Можно больше подробностей? Крайне необычный кейс.
Главная оптимизация Django админки, когда в ней надо работать с миллионами записей, — не использовать админку Django. Это хороший признак того, что пора писать свою специализированную под конкретные задачи штуку. Не обязательно с нуля, конечно.
Django Admin с миллионами записей — 11 практик оптимизаций для начинающих