On Tue, 2008-04-15 at 07:59 -0700, sector119 wrote:
> Template error
>
> In template /home/sector119/devel/eps_src/eps/templates/base.html,
> error at line 23
> Caught an exception while rendering: maximum recursion depth exceeded
> in cmp
>
> 23 <b>{{ user.office.location.get_type_display }}.
> 24 {{ user.office.location.name }},
> 25 {{ user.office.name }},
>
> ----------------------
>
> class Location(models.Model):
> id = models.IntegerField(_('Id'), primary_key=True)
> parent = models.ForeignKey('self', verbose_name=_('Location parent
> id:'), null=True, blank=True, related_name='child_set')
> name = models.CharField(_('Location'), help_text=_('Office or
> person location.'), max_length=32)
> type = models.PositiveSmallIntegerField(_('Location type'),
> choices=LOCATION_TYPE_CHOICES)
[...]
> class Meta:
> verbose_name = _('Location')
> verbose_name_plural = _('Locations')
> ordering = ['parent', 'id']
This is a combination of a bug in your code and a bug in
queryset-refactor. It is also something that is specific to
queryset-refactor because it fixes a bug in trunk, as noted below. The
queryset-refactor bug is now fixed, as of [7429], but all that does is
change the error you get. Now it will report that there is an infinite
ordering loop in the Location model (it already did this in most cases,
but I'd somehow broken the "related to 'self'" case and hadn't realised
it was behaving differently).
This is a case where queryset-refactor fixes a bug that exists in trunk
and thus the results change slightly, but only because trunk was doing
it wrong. The problem is that to order by the 'parent' model properly,
we need to order those parents by their own parents (since that is the
ordering on the parent model as well), which means we need to know how
to order the grandparents and then the great-grandparents and so on. And
what we don't know until we examine the data is how many levels of
ordering are involved here. In short, there is no way to construct an
SQL query that will correctly order by parents based on this data
structure. Django trunk just orders by the immediate parent, which, as I
said, doesn't raise an error, but it also isn't really correct or
intuitive.
Django queryset-refactor detects the infinite loop problem and reports
it as an error.
What you can do is order by 'parent_id', which is equivalent to the
current trunk behaviour, although it might not really be what you want.
That doesn't require joining Location to itself multiple times at the
SQL level, since the parent_id value is part of the Location table. But
you have to specify that manually, since ordering by ForeignKeys is
quite possible, providing there is not an infinite loop and it would be
lots of extra work for Django to work out the loop and then change the
meaning of the ordering field each time. So you need to get the right in
your own code.
Alternatively, you need to change your tree-like structure to include a
bit more additional information so that ordering of nodes in the tree
can be done. This is what django-mptt does and there are also lots of
articles around on the Web and in books about how to store tree-like
data structures in SQL.
Regards,
Malcolm
--
Honk if you love peace and quiet.
http://www.pointy-stick.com/blog/
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
