To help you understand and control the queries issued by your code, Django\nprovides a hook for installing wrapper functions around the execution of\ndatabase queries. For example, wrappers can count queries, measure query\nduration, log queries, or even prevent query execution (e.g. to make sure that\nno queries are issued while rendering a template with prefetched data).
\nThe wrappers are modeled after middleware –\nthey are callables which take another callable as one of their arguments. They\ncall that callable to invoke the (possibly wrapped) database query, and they\ncan do what they want around that call. They are, however, created and\ninstalled by user code, and so don’t need a separate factory like middleware do.
\nInstalling a wrapper is done in a context manager – so the wrappers are\ntemporary and specific to some flow in your code.
\nAs mentioned above, an example of a wrapper is a query execution blocker. It\ncould look like this:
\ndef blocker(*args):\n raise Exception('No database access allowed here.')\nAnd it would be used in a view to block queries from the template like so:
\nfrom django.db import connection\nfrom django.shortcuts import render\n\ndef my_view(request):\n context = {...} # Code to generate context with all data.\n template_name = ...\n with connection.execute_wrapper(blocker):\n return render(request, template_name, context)\nThe parameters sent to the wrappers are:
\nexecute – a callable, which should be invoked with the rest of the\nparameters in order to execute the query.
sql – a str, the SQL query to be sent to the database.
params – a list/tuple of parameter values for the SQL command, or a\nlist/tuple of lists/tuples if the wrapped call is executemany().
many – a bool indicating whether the ultimately invoked call is\nexecute() or executemany() (and whether params is expected to be\na sequence of values, or a sequence of sequences of values).
context – a dictionary with further data about the context of\ninvocation. This includes the connection and cursor.
Using the parameters, a slightly more complex version of the blocker could\ninclude the connection name in the error message:
\ndef blocker(execute, sql, params, many, context):\n alias = context['connection'].alias\n raise Exception("Access to database '{}' blocked here".format(alias))\nFor a more complete example, a query logger could look like this:
\nimport time\n\nclass QueryLogger:\n\n def __init__(self):\n self.queries = []\n\n def __call__(self, execute, sql, params, many, context):\n current_query = {'sql': sql, 'params': params, 'many': many}\n start = time.monotonic()\n try:\n result = execute(sql, params, many, context)\n except Exception as e:\n current_query['status'] = 'error'\n current_query['exception'] = e\n raise\n else:\n current_query['status'] = 'ok'\n return result\n finally:\n duration = time.monotonic() - start\n current_query['duration'] = duration\n self.queries.append(current_query)\nTo use this, you would create a logger object and install it as a wrapper:
\nfrom django.db import connection\n\nql = QueryLogger()\nwith connection.execute_wrapper(ql):\n do_queries()\n# Now we can print the log.\nprint(ql.queries)\nconnection.execute_wrapper()Link to this heading#Returns a context manager which, when entered, installs a wrapper around\ndatabase query executions, and when exited, removes the wrapper. The wrapper is\ninstalled on the thread-local connection object.
\nwrapper is a callable taking five arguments. It is called for every query\nexecution in the scope of the context manager, with arguments execute,\nsql, params, many, and context as described above. It’s\nexpected to call execute(sql, params, many, context) and return the return\nvalue of that call.