This is exactly the part I'm not sure how to make better.  I can make it
all into one gigantic query, but then I end up storing all of the data in
memory, and doing a bunch of processing in python loops and repacking
everything.  So my "let postgres do the heavy lifting" and "minimize the
number of queries" instincts conflict.  This was the easier one to code, so
I did it :) .

So if someone understands databases better than I and can say one of these
is definitely better, I'm happy to do it.  Or if someone knows how to do
some sort of profiling on it.  Otherwise, this works not-unreasonably, and
it will be a feature used once in a while anyway, so it may not matter much.


On Wed, Jan 2, 2013 at 5:51 AM, Anthony Lu <notifications@github.com> wrote:

> In esp/esp/survey/views.py:
>
> > +        for s in surveys:
> > +            s.display_data = {}
> > +
> > +            #load questions, and pack which column each goes in
> > +            s.display_data['questions']=s.questions.filter(anchor=prog.anchor).order_by('seq','id')
> > +            col=1
> > +            s.display_data['questions_dict']={}
> > +            for q in s.display_data['questions']:
> > +                s.display_data['questions_dict'][q.id]=col
> > +                col+=1
> > +
> > +            #load responses and answers, and pack answers into response objects
> > +            s.display_data['responses']=s.surveyresponse_set.all()
> > +            a=Answer.objects.filter(question__in=s.display_data['questions']).select_related('question', 'question__question_type','survey_response')
> > +            for r in s.display_data['responses']:
> > +                r.display_answers=a.filter(survey_response=r).order_by('question__seq','question__id')
>
> So, I haven't read this closely enough to understand what it's doing
> fully, but since you were asking about being stupid about query performance
> -- database query inside nested for-loop raises a red-flag for me. Also
> below, in lines 249 and 252.
>
> If it runs in reasonable time as-is, and there isn't an obvious way to
> un-nest the queries using related lookups, then I wouldn't worry about it.
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/learning-unlimited/ESP-Website/pull/537/files#r2527452>.
>
>