You want to change your perspective on how you look at this.
Templates are not “code”, they don’t execute.
The rendering engine reads the template and processes it as text. When it’s parsing the text, the {{ }} symbols are handled as a reference to a variable.
What you would need to identify is whether or not the rendering engine is async, and I’m fairly sure the answer to that is currently “no”. (I can find no evidence in the docs or the code to give me any indication that it is.)
If you believe that there is an advantage to you executing this query in an async mode, then you will want to ensure the queryset is resolved in the view before handing it off to the rendering engine.
Thank Ken, I know they do not execute. But whatever the terminology, the idea is that querysets are lazy and that once called in templates (and field “extracted” from them?), they are “unlazyfied”.
That’s too bad if the templating/rendering engine is not async. :[
Guess the (awesome) django team has already quite a lot to do…
Then to react to “you will want to ensure the queryset is resolved in the view”. How? list(queryset) seems to be excluded:
Be aware that you also can’t do other things that might iterate over the queryset, such as wrapping list() around it to force its evaluation (you can use async for in a comprehension, if you want it).
so something like this?
async def get_context_data(self):
# get parent context
objs = Model.objects.filter(...)
objs_list = []
async for obj in objs:
objs_list.append(obj)
context['objs'] = objs_list
# or like this?
context['objs'] = [obj async for obj in objs]
return context
If the template rendering engine would not support being async, then you could not have async functiona-based-views, no? I believe that async class-based-views are not yet supported, which trickles down to not being able to use async template rendering in CBVs.