Opened 14 years ago

Closed 14 years ago

Last modified 14 years ago

#15577 closed (invalid)

inefficient design of inlinemodeladmin

Reported by: yoav@… Owned by: nobody
Component: contrib.admin Version: 1.2
Severity: Keywords:
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

The problem we are trying to highlight is that with larger datasets, the inline admin is extremely inefficient and becomes impossible to work with. It loads the ENTIRE dataset and dumps it into the page as options. This is fine for small-ish data-sets, but unworkable with bigger ones.

We have created a small project on github to demonstrate this issue https://github.com/Azd325/django-admin-inline-bug

This was tested with Django 1.2.5 as well as the latest trunk and produces the same results.

The project includes code taken directly from the Django documentation, with no further changes. i.e.
http://docs.djangoproject.com/en/1.2/ref/contrib/admin/#working-with-many-to-many-models

We have used the Person<->Membership<->Group many-to-many model. The initial data (included in the fixtures) creates 10,000 Person records on the database, with a single Group object, of which there is only one member currently.

Managing the group via django admin (e.g. /admin/big_group/group/1/) shows that the page includes ALL people, regardless of group membership, as a HTML select.

The HTML would include this:

<select name="membership_set-0-person" id="id_membership_set-0-person">
<option value="">---------</option>
<option value="1" selected="selected">Person object</option>
<option value="2">Person object</option>
<option value="3">Person object</option>
...
<option value="9999">Person object</option>

and it does it not only once, but as many times as there are members. So if you have a 10,000 person records, with 100 members of a group, changing the group membership via the django admin would load 1,000,000 records into the HTML.

Perhaps the inline design should change to only load the right objects that are part of the relationship (with an option to add/delete/modify). Otherwise, maybe the documentation should highlight this potential issue, so users of django admin inlines are aware of it.

Tim Kleinschmidt + Yoav Aner

Change History (4)

comment:1 by Russell Keith-Magee, 14 years ago

Resolution: invalid
Status: newclosed

This is what raw_id_fields is for.

comment:2 by yoav@…, 14 years ago

Resolution: invalid
Status: closedreopened

Thanks for pointing it out. Looks like we missed this. It might still be worthwhile highlighting more explicitly in the documentation?

So using the raw_id_fields minimizes queries for the whole list, but then you lose the functionality you get with the little plus sign allowing you to add a member by name. Or maybe we're missing something out here as well??

comment:3 by anonymous, 14 years ago

Resolution: invalid
Status: reopenedclosed

Absent a specific suggestion for what to put in the documentation, it's hard to do anything useful here.

You can in fact add a new entry, after clicking the looking-glass icon. That will bring up a panel where you can search for and choose from an existing object or (in the upper right) create a new one.

comment:4 by yoav@…, 14 years ago

Perhaps this is an RTFM issue, but we failed to notice this or figure out the subtleties when reading through the documentation.

To some extent, we'd expect the opposite from the default behaviour. i.e. That the Inline would use just the linked foreign fields by default instead of loading all objects, and only if you really want to load ALL objects, you can specify it the other way. The way we looked at it was that the Inline allows you to access other fields that are a part of this relationship, not others which are not.

In any case it was an interesting learning experience.

Note: See TracTickets for help on using tickets.
Back to Top