Opened 7 years ago

Closed 7 years ago

#7362 closed (wontfix)

Admin model editor executes thousands of SQL commands when foreign key referenced in __str__

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

Description

I have three models in my application:

class State(models.Model):
   name = models.CharField(max_length=20,unique=True)
   code = models.USStateField()
   def __str__(self):
        return self.name

class Location(models.Model):
   zipcode = models.CharField(max_length=5,primary_key=True,core=True)
   state = models.ForeignKey(State,core=True)
   city = models.CharField(max_length=64,core=True)
   def __str__(self):
      return self.city + ', ' + str(self.state.code) + str(self.zipcode)

class Company(models.Model):
   name = models.CharField(max_length=64,unique=True)
   address = models.CharField(max_length=128)
   location = models.ForeignKey(Location,null=False,blank=True)
   def __str__(self):
      return self.name

When I try to edit a company record, the page hangs forever because in the background Django is executing a lookup query on the state. The following is from my MySQL 5.0.45 server's query log:

<SNIP>
3274 Query       SELECT `generator_state`.`id`,`generator_state`.`name`,`generator_state`.`code` FROM `generator_state` WHERE (`generator_state`.`id` = 46)
3274 Query       SELECT `generator_state`.`id`,`generator_state`.`name`,`generator_state`.`code` FROM `generator_state` WHERE (`generator_state`.`id` = 46)
3274 Query       SELECT `generator_state`.`id`,`generator_state`.`name`,`generator_state`.`code` FROM `generator_state` WHERE (`generator_state`.`id` = 46)
3274 Query       SELECT `generator_state`.`id`,`generator_state`.`name`,`generator_state`.`code` FROM `generator_state` WHERE (`generator_state`.`id` = 46)
3274 Query       SELECT `generator_state`.`id`,`generator_state`.`name`,`generator_state`.`code` FROM `generator_state` WHERE (`generator_state`.`id` = 50)
3274 Query       SELECT `generator_state`.`id`,`generator_state`.`name`,`generator_state`.`code` FROM `generator_state` WHERE (`generator_state`.`id` = 50)
<SNIP>

If I remove the __str__() method from the Location model, then the admin editor form loads just fine!

There are a couple weird things about this problem. First is that the admin listing page works fine, as well using the model in the actual application). The second weird thing is that that the state_id used in SQL lookups seem to be random -- that is they don't reference the state used in the Location record. Lastly, is that I still have this problem even if Company.location is not included in the Admin.fields property.

I'm not sure if this is a genuine bug, or if this something that somebody has said "don't do that" before.

I am using py25-django-devel-20080404 installed on FreeBSD 6.2

Change History (2)

comment:1 Changed 7 years ago by Andy Pavlo <Andrew_Pavlo@…>

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

I played around with this a bit more and it looks like the flood of queries is that the Django is always trying to prepare the Location drop down and it does a separate state id lookup for each zip code (which has almost 30,000 records). I was not expecting this because I had not added the location field to the Company's Admin.field list. By adding either {{raw_id_admin=True}} or {{editable=False}} to Company.location, Django no longer prepares the dropdown and I don't suffer from the SQL deluge.

It seems to me that Django should know whether a field is included in the admin edit page or not, and not try to load everything in.

comment:2 Changed 7 years ago by russellm

  • Resolution set to wontfix
  • Status changed from new to closed

This bug is well known (and I'm pretty sure has been reported before). The problem is fundamental to the way oldforms was built, and the current admin interface depends on oldforms. This was one of the major factors leading to decision to develop newforms, and to reimplement the admin interface using newforms.

Fixing problems in the existing admin interface is a lot of work, so we're marking all bug reports against the existing admin as 'wontfix'. Instead, we're focussing our efforts on finishing the implementation of newforms-admin.

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