It’s now a long-running tradition that each Django release has an associated “code word”. This is used by the release manager in the announcement blog post to describe the list of features coming in the next version.
I wrote my library time-machine last year as a way to speed up tests that need to accurately mock the current time.
Django 3.2 had its first alpha release a couple of weeks ago and the final release will be out in April. It contains a mezcla of new features, which you can check out in the release notes. This post focuses on the changes to testing, a few of which you can get on earlier Django versions with backport packages.
Yet another use case for creating a database constraint with Django’s CheckConstraint class.
Here’s another use case for creating a database constraint with Django’s CheckConstraint class.
For all my linting needs these days I use the pre-commit framework. It has integrations with every tool I want to use, and uses Git’s hooks to prevent non-passing code from ever being committed.
I recently optimized a client project’s test suite, and in the process found a test whose runtime had crept up ever since it had been written. The problematic test exercised an import process from a fixed past date until the current day. The test’s runtime therefore grew every day, until it reached over a minute.
For my new Django project, DB Buddy, I’m using CloudFlare as my CDN. It has a bunch of useful features that would otherwise take extra work, such as DDoS protection, HTML minification, and analytics.
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.
If you start the development server on a Django project, it looks something like this:
In recent years browsers have gained many powers to report back problems they encounter on your site, such as:
Today I learned about the better-exceptions package. It makes exception output better, providing more context and colourization on the terminal.
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:
If you’re testing Python code that relies on the current date or time, you will probably want to mock time to test different scenarios. For example, what happens when you run a certain piece of code on February 29? (A common source of bugs.)
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.
If you’ve used Django migrations for a while, you may be familiar with this message:
Earlier this week I tweeted about my two part offer on my book Speed Up Your Django Tests for this year’s Cyber Monday.
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.
Sometimes tests need to change environment variables. This is fairly straightforward in pytest, thanks to os.environ quacking like a dict, and the mock.patch.dict decorator/context manager.
Sometimes, tests need to change environment variables. This is straightforward in tests using Python’s unittest, thanks to os.environ quacking like a dict, and the mock.patch.dict decorator/context manager.
Last week, I released a new Django package, django-read-only. It provides a read-only mode for Django’s database layer.
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?
There are a few mini sites out there with “bonus” Django documentation. Here’s a list of the best ones I know of.
The N+1 Queries Problem is a perennial database performance issue. It affects many ORMs and custom SQL code, and Django’s ORM is not immune either.