Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Django admin list_display not showing several objects

I have just begun to play around with Django admin views, and to start off, I am trying to do something very simple: showing several fields in the listing of objects using list_display as explained here: https://docs.djangoproject.com/en/dev/ref/contrib/admin/

This is my dead simple code:

class ArticleAdmin(admin.ModelAdmin):
     list_display = ('title', 'category')

Unfortunately, the list_display option is causing the columnar view to appear, but only some of the objects (40 out of 85) are now displaying in the listing. I cannot deduce why certain objects are showing over the others - their fields look like they are filled similarly. It's clearly not paginating, because when I tried it on an admin of another model, it showed only 2 objects out of about 70 objects.

What might be going on here?

[UPDATE] Article Model:

class Article(models.Model):
    revision = models.ForeignKey('ArticleRevision', related_name="current_revision")
    category = models.ForeignKey('meta.Category')
    language = models.ForeignKey('meta.Language', default=get_default_language)
    created = models.DateTimeField(auto_now_add=True, editable=False)
    changed = models.DateTimeField(auto_now=True, editable=False)
    title = models.CharField(max_length=256)
    resources = models.ManyToManyField('oer.Resource', blank=True)
    image = models.ManyToManyField('media.Image', blank=True)
    views = models.IntegerField(editable=False, default=0)
    license = models.ForeignKey('license.License', default=get_default_license)
    slug = models.SlugField(max_length=256)
    difficulty = models.PositiveIntegerField(editable=True, default=0)
    published = models.NullBooleanField()
    citation = models.CharField(max_length=1024, blank=True, null=True)

Before adding list_display:

Django amdin before list_display

After adding list_display:

Django amdin after list_display

[UPDATE] This behaviour occurs only when ForeignKey fields are included in list_display tuple. Any of them.

[UPDATE] Category model code:

class Category(models.Model):
    title = models.CharField(max_length=256)
    parent = models.ForeignKey('self')
    project = models.NullBooleanField(default=False)
    created = models.DateTimeField(auto_now_add=True, editable=False)
    slug = models.SlugField(max_length=256, blank=True)

    def __unicode__(self):
        return self.title
like image 579
Varun Arora Avatar asked May 03 '13 17:05

Varun Arora


1 Answers

This behavior is caused by a foreign key relation somewhere that is not declared as nullable, but nonetheless has a null value in the database. When you have a ManyToOne relationship in list_display, the change list class will always execute the query using select_related. (See the get_query_set method in django.contrib.admin.views.ChangeList).

select_related by default follows all foreign keys on each object, so any broken foreign key found by this query will cause data to drop out when the query is evaluated. This is not specific to the admin; you can interactively test it by comparing the results of Article.objects.all() to Article.objects.all().select_related().

There's no simple way to control which foreign keys the admin will look up - select_related takes some parameters, but the admin doesn't expose a way to pass them through. In theory you could write your own ChangeList class and override get_query_set, but I don't recommend that.

The real fix is to make sure your foreign key model fields accurately reflect the state of your database in their null settings. Personally, I'd probably do this by commenting out all FKs on Article other than Category, seeing if that helps, then turning them back on one by one until things start breaking. The problem doesn't have to be with a FK on an article itself; if a revision, language or category has a broken FK that will still cause the join to miss rows. Or if something they relate to has a broken FK, etc etc.

like image 81
Peter DeGlopper Avatar answered Sep 27 '22 22:09

Peter DeGlopper