On Tue, 2009-05-05 at 21:59 -0500, Keith Pettit wrote:
> I'm trying to display a list on a page that is a combination of two
> different models. In development I use sqlite and the list works
> great, but when I go to MySQL I don't get any results. It's odd
> because I use pagination and I can see from my paging items there are
> some results but I can't call them from template. I'm not sure if
> this is considered a bug or something lacking in features for MySQL.
> The View, Template and Model info are below.
Since select_related() should not change the results that are returned
(it reduces the number of database query, but doesn't change the net
result set), you should initially remove all uses of select_related() in
trying to debug your problem. If it works then and doesn't work in some
way when you add select_related() in one particular place (not all at
once), then that's an interesting data point.
>
> I've tried Django 1.0.2 and Django SVN-1.1-10678. Both versions work
> with sqlite and both fail with MySQL.
>
> Thanks for any help,
>
> Keith
>
>
> View:
> return render_to_response('ticket/ticket_list.html', {'object_list':
> Ticket.objects.all().select_related()})
Debugging is all about removing variables from the thing you're testing.
In this case, passing a whole bunch of stuff through the view to the
template and only viewing the template output is adding an extra,
potentially unnecessary layer to the debugging. My first step in looking
at this problem (well, second step, since the first step is to remove
the call to select_related() for the reasons mentioned above) would be
print out what Ticket.objects.all() returns. Is it empty with on the
databases at this point, *before* being put in a dictionary and passed
to the template for rendering? Or is there data at this point and no
data later on?
>
> Template:
> {% if object_list %}
> {{ object_list.as_table}}
Not sure what you're expecting to happen here, as a Ticket instance
doesn't have an as_table() method. This will be harmless (it will fail
silently), but it's unlikely to be doing what you want.
In any case, in the spirit of reducing the problem as much as possible
when debugging, I would be getting rid of *everything* unnecessary in
this template. If you've verified that the view is passing a non-empty
object_list through to here, now put something like {{ object_list|
length }} into the template to verify it's still non-empty.
> {% for object in object_list %}
Does "object" contain something sensible at this point?
> {% for load in object.load_set.select_related %}
Do you get to this point? Is there anything *in* the inner loop to loop
through?
I can't see any particular reason for the behaviour you're seeing.
However, your example has a lot of lines of code in there, so I might
well be missing something. Try hard to reduce things as much as
possible. Create simpler models for debugging purposes, so you're not
debugging something with a few dozen fields involved (particularly if
you need to end up looking at the SQL that is generated). Try printing
out the same results in the view, just to verify they are retrieved
correctly. Things like that. At the moment, you have about 350 moving
parts involved, which is roughly 348 too many for the first phase of
debugging something like this.
Regards,
Malcolm
--~--~---------~--~----~------------~-------~--~----~
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
django-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
