Add a system check for context processors which trigger database queries

[Keryn Knight <django@…>]

The ease-of-use of context processors, and the ORM, make it easy to accidentally introduce additional queries that are run whether or not the variable is ever used. This is mostly a problem encountered by newer folk, who've never needed to optimise away to the degree that this might matter, but by not tutoring them early, the risk is that the habit persists -- I still forget, sometimes, for example.

I'd propose that a new check be added which is of Info or Warning level, that can be used to alert the user that context processor X triggers database queries. The way I'm imagining it'd have to work would be to avoid using any of the Template Loaders, because they might be swapped out for something like DB templates.

In pseudo-code (because I've certainly not looked at the actual checks implementation), something like:

with self.assertNumQueries(0):  # ie: do the same work to capture the connection's query count, but obviously not as a unit test
    template = Template("{{ test }}")
    context = RequestContext(RequestFactory().get('/'))
    context.update(test=True)
    template.render(context)

This *should* sidestep anything that loads from the database (though conceivably if someone is somehow storing settings in the database, that'd be a problem) and run through the defined TEMPLATE_CONTEXT_PROCESSORS to discover any DB access leaks. In theory one could go so far as to get the set intersection between the default/Django-provided context processors (none of which explicitly touch the database AFAIK) and those defined for the project, to keep the work minimal.

How the wisdom of being lazy is imparted to the user, I'm not sure. Perhaps a link to the docs for Django version {{ x }}, though I think that would by necessity mean exposing/documenting the lazy helpers, which have passing mentions in the docs, but are otherwise hidden away.

[Tim Graham]

I'm not sure if this is feasible. So far the system check framework is more of a static analysis. from Russ: "System check doesn't do a scan of code looking for potentially problematic code usage; it just checks models and other formal declarations for problems that would prevent startup or cause known problems."

[Keryn Knight <django@…>]

Ah, that's fair enough. I'll close as an invalid use of the check framework, then.

Should the system checks usage ever shift towards providing guidelines and hints to developers, and this ticket becomes useful, a quickly whipped together implementation of the check I was suggesting is ​here.