Pull to refresh

Comments 10

эээ ребят, ModelAdmin.show_full_result_countNew in Django 1.8 (April 1, 2015)

Этого недостаточно, к сожалению.

show_full_result_count скрывает только общее число результатов из отфильтрованных. Что делать, если даже с учетом фильтров остаются миллионы записей, документация Django умалчивает. В результате - запрос COUNT с учетом фильтра, текст вверху вида "2575 results (Show all)" и пагинатор на 100500 страниц после списка. Хотя нет. В результате - 504.

недавно делал два доклада тут и тут, как раз про админку Django.

  1. Стандартный select / raw_id_fields в принципе то да, для новой джанго завезли уже select2 из коробки. Работает отлично. Правда, ломает grapelli, если у кого стоял.

  2. Фраза "выгружайте все необходимое одним запросом несовместима" с prefetch_related. Данные полей prefetch_related догружаются после отдельными запросами. Я бы в статье добавил активное использование "only", вот эта штука здорово заставляет подумать и получить только то, что надо.

  3. Стоит убедится, что нигде не указываете ordering. Увы, даже если нигде ничего не указано, джанго приклеит .order_by(model._meta.pk.name)

  4. SHOW TABLE STATUS LIKE table_name, не работает в случае предварительных фильтров. В случае мультитеннантности на разнобазовых запросах, придется переделывать запрос.

  5. 25 раз по мало < 1 раз много. Согласен, другой вопрос, если данные второй таблицы точно присутствуют, то можно переопределить тип джоина на INNER JOIN. для больших таблиц может быть быстрее.

  6. перегрузить поиск. Прям да. В одном из моих проектов только этим и спасались. Только конечно все намного глобальнее. Сначала собирали ID по моделям из ModelAdmin.search_fields и потом filter(linked_model__id_in=id_set).

  7. продумай заранее индексы. Спорно, поскольку заранее "соломку" не всегда успеешь подстелить. Про индексы в таблице с 62mln строк была Альбина Альмухаметова на pycon 2021 с докладом "Оптимизация i-запросов в Django+Postgres". От себя скажу, что один раз в моей жизни для убыстрения запросов индекс пришлось удалять.

  8. сложные фильтры в админке. Бывает. Бизнесу не прикажешь работать проще. Но посмотреть на запросы стоит, иногда можно сформировать зпрос проще, чем это делает родной ORM

  9. Работает только с недавнего момента. В ранних версиях Django возвращает EmptyQuerySet вместо type(super().get_queryset(request)). Если класс был переопределен, то все ломалось.

  10. Не знаешь зачем тебе данные, не показывай. Понимаю что речь немного о другом, но сюда подходит текст про only. Этот метод точно заставить подумать "нужны ли мне все данные которые я получаю из базы".

  11. Группируй модели в группы по смыслу. Вместо предложенной сомнительной батарейки можно использовать смысловое группирование по множественным SiteAdmins. Я в своих проектах использую именно эту возможность Django.

Мой вывод, что Django Contrib Admin + прямые руки помогут и графики показать и запросы сложные сделать и лишние батарейки деинсталлировать. Для красоты мне не хватает анимаций и переходов "из коробки", это пришлось допиливать другими средствами.

Спасибо @WarmongeR. Жаль я не прочел это в 2017. Пришлось разбираться самому.

Отличное дополнение! А где можно почитать про множественные SiteAdmins?

Можно посмотреть меня на видео с PyCon второй день, первое выступление. Вроде видео уже есть. Или подождать когда я выложу статью. Увы в документации минимум.

 один раз в моей жизни для убыстрения запросов индекс пришлось удалять.

Можно больше подробностей? Крайне необычный кейс.

django_admin_log индекс на какое-то из строковых obj_repr или message. При высокой частоте записи в лог.

Почему так, человечьим языком обьясняется тут

Главная оптимизация Django админки, когда в ней надо работать с миллионами записей, — не использовать админку Django. Это хороший признак того, что пора писать свою специализированную под конкретные задачи штуку. Не обязательно с нуля, конечно.

Sign up to leave a comment.

Articles