A client project recently was suffering from an N+1 queries problem in a complicated Django admin page. Many measures had already been taken to prevent N+1 queries, such as use of django-auto-prefetch and some manually tuned select_related() / prefetch_related() calls. The remaining N+1 in question was a bit resistant to those methods because it came through several layers of admin code and many-to-many fields, making it harder than normal to find the place to modify the QuerySet construction.
In all current releases of the popular WSGI server gunicorn, the Server header reports the complete version of gunicorn. I spotted this on my new project DB Buddy. For example, with httpie to check the response headers:
It can be tricky to ensure all the environments that your project runs on use the same versions of Python, PostgreSQL, and other external dependencies. Often development, CI, and cloud environments have different configuration systems, making them hard to keep in sync. And coordinating between all your team members to upgrade their local environments can be complicated, as upgrade emails or instant messages get forgotten if they are away on holiday, working on other projects, etc. And using the wrong versions of external dependencies can lead to hard-to-debug errors, wasting time to find such a simple fix.
I previously covered writing a Django application in a single file, for both synchronous and asynchronous use cases. This post covers the angle of creating a REST API using Django in a single file.
When we write custom management commands, it’s easy to write integration tests for them with call_command(). This allows us to invoke the management command as it runs under manage.py, and retrieve the return code, standard output, and standard error. It’s great, but has some overhead, making our tests slower than necessary. If we have logic separated out of the command’s handle() method, it improves both readability and testability, as we can unit test it separately.
You run your tests with manage.py test. You know what happens inside your tests, since you write them. But how does the test runner work to execute them, and put the dots, Es, and Fs on your screen?
Last week I covered Django’s database instrumentation, and making a wrapper that’s always installed. Here’s a different use case that I encountered last year on a project.
Since version 2.0, Django has provided a hook for installing database instrumentation wrapper functions. These functions are like middleware for database queries, allowing you to inspect and rewrite SQL before it is sent to the database. There are many use cases, for example:
Django’s test command takes the --parallel flag to activate parallel testing. Unfortunately, this has never worked on Windows, and with Python 3.8 it has stopped working on macOS.
Since I launched my book Speed Up Your Django Tests I’ve had a number of questions about possible discounts. I want to make my book affordable for all and understand that $49 is a high price tag for some. The Django community is global and I want to share knowledge with Djangonauts everywhere.
Imagine we are installing the third party package django-cors-headers, which I maintain. Step one in its installation process is to install the package, so we run the command:
The /.well-known/ URL path prefix is a reserved name space for serving particular static files used by other systems that might interact with your site. It was established by RFC 5785 and updated in RFC 8615. The IANA maintains a list of possible files in the Well Known URIs registry, but others are in wide use without official registration (yet?).
Django’s test client is really useful for writing integration tests for your project. It’s great because it has a simple API for testing your application similarly to how a web browser would interact with it. Unfortunately it can be slow, because each call creates a request, passes it through all your middleware, view, maybe a template, then the response comes back through the same layers.
This is a test anti-pattern I’ve seen creep in on many Django test suites. I know of several large projects where it became a major undertaking to undo it. The good news is it’s easy to avoid adding it when you first write your tests. 🙂