Администратор Django зависает (до ошибки тайм-аута) для конкретной модели при попытке редактировать/создавать

Этот человек сейчас меня заводит. Раньше этого не было (даже скриншоты, которые я должен был сделать для руководства пользователя, так как это требовало заказчика).

Я впервые заметил его на сервере production, а затем я проверил и также произошел в dev-сервере, который поставляется с Django. Модель появляется на главной странице администратора django, я могу щелкнуть по ней и отобразить список точек продаж. Проблема возникает, когда я хочу отредактировать существующий экземпляр или создать новый.

Я просто нажимаю на ссылку (или кладу ее на панель), и она просто зависает.

class PointOfSaleAdmin(admin.ModelAdmin):
    list_display = ('id','business', 'user', 'zipcode', 'address','date_registered')
    list_filter = ('business',)
    filter_horizontal = ('services',)
admin.site.register(models.PointOfSale, PointOfSaleAdmin)

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

class PointOfSale(models.Model):
    user = models.ForeignKey(User)
    zipcode = models.ForeignKey(Zipcode)
    business = models.ForeignKey(Business)
    services = models.ManyToManyField(Service, 
        verbose_name='available services')
    date_registered = models.DateField(auto_now_add=True)
    address = models.CharField(max_length=300)

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

Администратору очень редко приходится обращаться к этой странице. Обычно это просто перечисление PoS, но это все еще беспокоит меня. Любая идея, почему это может быть висит? Все остальные модели работают отлично.

Это происходит как на Django 1.2.5, так и на 1.3

EDIT:

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

Мне почти хочется похлопать себя. Моя вина за то, что ты так долго не спишь.

Проблема в том, что список zipcode довольно большой (десятки тысяч), а поле внешнего ключа загружается как тэг select html, что означает, что он загружает каждую запись. Это проблема с тем, сколько данных просто.

Теперь мне интересно, как управлять тем, как внешний ключ отображается в администраторе. Кто-нибудь может помочь с этим?

Ответ 1

В вашем файле admin.py под соответствующим классом администратора установите

raw_id_fields = ('zipcode',)

Это приведет к отображению PK вместо zpcode.

Есть ли причина, по которой вы настраиваете zipcode как свою собственную модель вместо использования CharField или фактического zipcode modelfield?

Ответ 2

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

class FlaggedCommentsAdmin(ModelAdmin):
    list_display = ('user', 'discussion', 'flagged_on')
    readonly_fields = ('user', 'discussion')

Ответ 3

Пробовали ли вы проверять журналы apache (если вы используете apache явно) или любые другие журналы, связанные с HTTP-сервером? Это может дать вам представление о том, с чего начать.

Это единственная модель, которая затронута? Вы упомянули методы на модели. Попробуйте прокомментировать эти методы и повторите попытку (включая метод __unicode__), чтобы убедиться, что они каким-то образом повлияли на него. Уменьшите все до минимума (насколько это возможно, очевидно), чтобы попытаться определить, где началась регрессия.

Попытайтесь контролировать ресурсы сервера при запросе этой страницы. Является ли процессор резким скачком? Что можно сказать о сетевом вводе-выводе? Может быть проблема с базой данных (как-то?).

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

Ответ 4

Для людей, которые все еще заходят на эту страницу: как указывает Мамсаак в своем первоначальном сообщении, тайм-аут происходит из-за того, что django пытается загрузить все экземпляры ForeignKey в html-выбор. Django 2 позволяет вам добавить поле автозаполнения, которое асинхронно позволяет вам искать ForeignKey, чтобы справиться с этим. В вашем admin.py сделайте что-то вроде этого:

from django.contrib import admin
from .models import Parent, Child

@admin.register(Parent)
class ParentAdmin(admin.ModelAdmin):
    # tell admin to autocomplete-select the "Parent"-field 'children'
    autocomplete_fields = ['children']

@admin.register(Child)
class ChildAdmin(admin.ModelAdmin):
    # when using an autocomplete to find a child, search in the field 'name'
    search_fields = ['name']