简体   繁体   English

加速Django Admin删除页面

[英]Speeding Up the Django Admin Delete Page

How would you speed up the Django Admin record deletion action/page? 你会如何加快Django Admin记录删除操作/页面的速度?

I have a model B with a foreign key constraint to model A. For every record in A, there are about 10k records in B bound to A. So when I have to delete a record in A using the default "Delete selected A" action in admin, Django will take 15 minutes to query and display every record being deleted in B. How would I modify this so instead of listing thousands of dependent objects, it only displays a count of the dependent objects being deleted? 我有一个模型B,对模型A有一个外键约束。对于A中的每个记录,B中约有10k条记录绑定到A.所以当我必须使用默认的“删除选定的A”动作删除A中的记录时在管理员中,Django将花费15分钟来查询并显示在B中删除的每个记录。我将如何修改它,而不是列出数千个依赖对象,它只显示被删除的依赖对象的计数?

As usual browse the django source to find your answer (it's surprisingly readable with variables, functions, classes, and files named logically). 像往常一样浏览django源代码来找到你的答案(它具有令人惊讶的可读性,包括逻辑命名的变量,函数,类和文件)。

Looking at django/contrib/admin/templates/admin/delete_confirmation.html (in django 1.2.5), you will see a template that has the 24th line contains: 查看django/contrib/admin/templates/admin/delete_confirmation.html (在django 1.2.5中),您将看到一个包含第24行的模板:

<ul>{{ deleted_objects|unordered_list }}</ul>

If you change this to say 如果你改变这个说

<p>{{ deleted_objects|count }} objects</p>

or 要么

{% if 100 < deleted_objects|count %}
    <p>{{ deleted_objects|count }} objects</p>
{% else %}
    <ul>{{ deleted_objects|unordered_list }}</ul>
{% endif %}

it will only display the count of deleted objects (if there are many deleted objects). 它只显示已删除对象的数量(如果有许多已删除的对象)。

You may also want to experiment with editing django/contrib/admin/templates/admin/actions.py to use a SQL transaction to do the mass deletion more quickly. 您可能还想尝试编辑django/contrib/admin/templates/admin/actions.py以使用SQL事务更快地进行批量删除。 See: http://docs.djangoproject.com/en/dev/topics/db/transactions/ 请参阅: http//docs.djangoproject.com/en/dev/topics/db/transactions/

Basically action.py currently works by forming the appropriate queryset, calling delete() directly the queryset, but not grouping it into a single db transaction. 基本上,action.py通过形成适当的查询集,直接调用delete()查询集,但不将其分组到单个db事务中。 Doing simple time tests on a sample sqlite database I found that deleting ~150 objects without transactions took 11.3 seconds using qs.delete() and 13.4 seconds using for obj in qs: obj.delete() . 对示例sqlite数据库进行简单的时间测试我发现删除qs.delete()没有事务的对象使用qs.delete()需要11.3秒,而使用for obj in qs: obj.delete() 13.4秒。 Using transactions ( @transaction.commit_on_success before the deleting functions), the same commands took only 0.35 seconds and 0.39 seconds (about 30 times faster). 使用事务(删除函数之前的@transaction.commit_on_success ),相同的命令只需0.35秒和0.39秒(大约快30倍)。 Granted using transactions may lock the database temporarily, which may not be an acceptable option. 使用事务授予可能会暂时锁定数据库,这可能不是一个可接受的选项。

To extend the django admin sensibly (normally you wouldn't want to edit the source directly; especially if other users are using the same files or if you may ever want to revert back later or are running other django sites on the same machine) see: http://www.djangobook.com/en/1.0/chapter17/#cn35 明智地扩展django管理员(通常你不想直接编辑源代码;特别是如果其他用户使用相同的文件,或者你可能想要稍后恢复或在同一台机器上运行其他django站点) : http//www.djangobook.com/en/1.0/chapter17/#cn35

For Django 1.4 @drjimbob's recipe is slightly different: 对于Django 1.4 @ drjimbob的配方略有不同:

Update the file: 更新文件:

django/contrib/admin/templates/admin/delete_selected_confirmation.html

and on line 35 replace 并在第35行更换

{% for deletable_object in deletable_objects %}
    <ul>{{ deletable_object|unordered_list }}</ul>
{% endfor %}

for 对于

{% for deletable_object in deletable_objects %}
    {% if 100 < deletable_object|length %}
        <p>{{ deletable_object|length }} objects</p>
    {% else %}
        <ul>{{ deletable_object|unordered_list }}</ul>
    {% endif %}
{% endfor %} 

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM