date_hierarchy in admin weirdly broken

[geber@…]

My django Installation runns in fcgi. And I get an error like this pretty often:

Traceback:
File "/home/.../prod/lib/django/core/handlers/base.py" in get_response
  111.                         response = callback(request, *callback_args, **callback_kwargs)
File "/home/.../prod/lib/django/contrib/admin/options.py" in wrapper
  307.                 return self.admin_site.admin_view(view)(*args, **kwargs)
File "/home/.../prod/lib/django/utils/decorators.py" in _wrapped_view
  93.                     response = view_func(request, *args, **kwargs)
File "/home/.../prod/lib/django/views/decorators/cache.py" in _wrapped_view_func
  79.         response = view_func(request, *args, **kwargs)
File "/home/.../prod/lib/django/contrib/admin/sites.py" in inner
  197.             return view(request, *args, **kwargs)
File "/home/.../prod/src/../lib/mobileadmin/decorators.py" in _change_templates
  52.         return function(self, request, *args, **kwargs)
File "/home/.../prod/src/../lib/mobileadmin/decorators.py" in _change_templates
  52.         return function(self, request, *args, **kwargs)
File "/home/.../prod/lib/django/utils/decorators.py" in _wrapper
  28.             return bound_func(*args, **kwargs)
File "/home/.../prod/lib/django/utils/decorators.py" in _wrapped_view
  93.                     response = view_func(request, *args, **kwargs)
File "/home/.../prod/lib/django/utils/decorators.py" in bound_func
  24.                 return func(self, *args2, **kwargs2)
File "/home/.../prod/lib/django/contrib/admin/options.py" in changelist_view
  1179.         ], context, context_instance=context_instance)
File "/home/.../prod/lib/django/shortcuts/__init__.py" in render_to_response
  20.     return HttpResponse(loader.render_to_string(*args, **kwargs), **httpresponse_kwargs)
File "/home/.../prod/lib/django/template/loader.py" in render_to_string
  188.         return t.render(context_instance)
File "/home/.../prod/lib/django/template/base.py" in render
  123.             return self._render(context)
File "/home/.../prod/lib/django/template/base.py" in _render
  117.         return self.nodelist.render(context)
File "/home/.../prod/lib/django/template/base.py" in render
  744.                 bits.append(self.render_node(node, context))
File "/home/.../prod/lib/django/template/base.py" in render_node
  757.         return node.render(context)
File "/home/.../prod/lib/django/template/loader_tags.py" in render
  127.         return compiled_parent._render(context)
File "/home/.../prod/lib/django/template/base.py" in _render
  117.         return self.nodelist.render(context)
File "/home/.../prod/lib/django/template/base.py" in render
  744.                 bits.append(self.render_node(node, context))
File "/home/.../prod/lib/django/template/base.py" in render_node
  757.         return node.render(context)
File "/home/.../prod/lib/django/template/loader_tags.py" in render
  127.         return compiled_parent._render(context)
File "/home/.../prod/lib/django/template/base.py" in _render
  117.         return self.nodelist.render(context)
File "/home/.../prod/lib/django/template/base.py" in render
  744.                 bits.append(self.render_node(node, context))
File "/home/.../prod/lib/django/template/base.py" in render_node
  757.         return node.render(context)
File "/home/.../prod/lib/django/template/loader_tags.py" in render
  64.             result = block.nodelist.render(context)
File "/home/.../prod/lib/django/template/base.py" in render
  744.                 bits.append(self.render_node(node, context))
File "/home/.../prod/lib/django/template/base.py" in render_node
  757.         return node.render(context)
File "/home/.../prod/lib/django/template/loader_tags.py" in render
  64.             result = block.nodelist.render(context)
File "/home/.../prod/lib/django/template/base.py" in render
  744.                 bits.append(self.render_node(node, context))
File "/home/.../prod/lib/django/template/base.py" in render_node
  757.         return node.render(context)
File "/home/.../prod/lib/django/template/base.py" in render
  921.                     dict = func(*args)
File "/home/.../prod/lib/django/contrib/admin/templatetags/admin_list.py" in date_hierarchy
  254.                                                 last=models.Max(field_name))
File "/home/.../prod/lib/django/db/models/query.py" in aggregate
  321.         return query.get_aggregation(using=self.db)
File "/home/.../prod/lib/django/db/models/sql/query.py" in get_aggregation
  374.             in zip(query.aggregate_select.items(), result)
File "/home/.../prod/lib/django/db/models/sql/query.py" in resolve_aggregate
  316.             return int(value)

Exception Type: TypeError at /admin/devices/dsd/
Exception Value: int() argument must be a string or a number, not 'datetime.date'

I have no idea where it comes from. But restarting the apache (and all its fcgi instances and memcached) it works again. I really have no idea, how to solve this issue. Any ideas? Is it a django-bug? Do you need more information?

[Aymeric Augustin]

If I understand correctly, the problem occurs on a "dsd" model in a "devices" app.

First, could you check that your current database schema matches the output of ./manage.py sql devices? You may have made a mistake when altering your schema manually.

In order to reproduce this, we need the relevant parts of your "dsd" Model and ModelAdmin classes. Could you:

• create a new app, copy your "dsd" Model and ModelAdmin there, run syncdb,
• confirm that the bug happens,
• remove as much stuff as possible from the model and the admin, while checking that the bug still happens,
• give us the resulting minimal test case.

Our procedure is to close the bug until you provide this information. Please reopen it when you're ready. Thanks!

[geber@…]

I happend to get the same error again today: Totally new model, complete new application. First time, that I got that Error locally. I was able to solve it again via server restart (no cache restart here). But after a little while the error occured again, which is way, I disabled the date_hierarchy admin setting.

Here, my fairly simple models.py:

from django.db import models
from django.utils.translation import ugettext_lazy as _


class LogEntry(models.Model):
    
    
    STATUS_CHOICES = (
     (0, 'MODEM '),
     # ...
     (1124, 'SEND LOGFILE')
    )

    _serial = models.PositiveIntegerField(_('Serial'), max_length=5)
    tid = models.PositiveSmallIntegerField('TID')
    created_at = models.DateTimeField(_('Date'))
    code = models.PositiveSmallIntegerField(_('Code'), choices=STATUS_CHOICES, null=True)
    message = models.TextField(_('Message'))
    
    class Meta:
        ordering = ['-created_at']
        
    def __unicode__(self):
        return u'%s: %04d (%s-%s)' % (self.created_at, self.code is None and 9999 or self.code, self.serial, self.tid)
        
    @property
    def serial(self):
        return '%05d' % self._serial

And my admin.py:

from django.contrib import admin
from django.utils.translation import ugettext_lazy as _

from webservices.kvaterrormgmt.models import LogEntry
from utils.adminprefs import DefaultModelAdmin


class LogEntryAdmin(DefaultModelAdmin):
    #date_hierarchy = 'created_at'
    list_display = ('created_at', '_serial', 'tid', 'code', 'msg',)
    list_filter = ('code', '_serial', 'tid',)
    search_fields = ('message', 'serial',)
    
    def msg(self, obj):
        return u'<pre>%s</pre>' % obj.message
    msg.order_field = 'message'
    msg.allow_tags = True
    msg.short_desription = _('Message')

admin.site.register(LogEntry, LogEntryAdmin)

Just in case, my adminprefs:

from django.contrib import admin


class DefaultModelAdmin(admin.ModelAdmin):
    save_on_top = True
    list_select_related = True

I hope this helps.

[Aymeric Augustin]

Could you also tell us which version of Django and which database backend you are using?

[geber@…]

Django, just as it is selected in VERSION: 1.3
Sorry, about the Backend. MySQL, we use.

[Aymeric Augustin]

I set up MySQL, copied your code in a new app, syncdb, runserver, created a few objects, and as one might expect, everything works. It's really hard to debug this remotely.

Could you re-enable date_hierarchy so we're in a situation where the bug occurs again? Then I have three questions:

• does the bug only occur under fcgi, or did you also see it under manage.py runserver? I'm not sure what "I got that Error locally" means.
• once the bug occurs, is it systematic (it occurs again if you refresh the page, until you restart the server)? or is it still random?
• in addition to the traceback, could you post the values of the local variables in the last four frames? (Click the little arrow to show them.)

From my experiments, three aggregates are computed to create the changelist for your LogEntry objects. Here's the result of a pdb.set_trace() at the beginning of the innermost function of the traceback:

> /Users/myk/Desktop/django-trunk/django/db/models/sql/query.py(314)resolve_aggregate()
-> if value is None:
(Pdb) aggregate, value
(<django.db.models.sql.aggregates.Count object at 0x102222a10>, 2L)
(Pdb) c
> /Users/myk/Desktop/django-trunk/django/db/models/sql/query.py(314)resolve_aggregate()
-> if value is None:
(Pdb) aggregate, value
(<django.db.models.sql.aggregates.Max object at 0x10229d750>, datetime.datetime(2011, 5, 31, 21, 5, 16))
(Pdb) c
> /Users/myk/Desktop/django-trunk/django/db/models/sql/query.py(314)resolve_aggregate()
-> if value is None:
(Pdb) aggregate, value
(<django.db.models.sql.aggregates.Min object at 0x10229d8d0>, datetime.datetime(2011, 5, 31, 21, 4, 53))
(Pdb) c

Based on the traceback in your initial report:

• aggregate.is_numeric must be True, so it must be the first aggregate that crashes,
• but value must be a datetime object there, so it must be the second or third one.

I need the values of the local variables to continue this analysis.

[Aymeric Augustin]

Even though I haven't confirmed that this is a bug in Django, I'm going to accept the ticket and assign it to myself, because no one is going to pick it from the Unreviewed queue now.

[geber@…]

Sentry Traceback including all Local Vars and the entire environment.

[geber@…]

1. Yes, it occurred in both fcgi and runserver (runserver only once, but it did)
2. Yes, it is then systematic
3. I can't provoke errors in our production servers, but we use sentry, so, please see attachment - hope it helps (and doesn't open any security issues on our side)

Your assumptions are correct, as far as I understand the problem.

Hope I was able to help in analyzing the problem.