Want to know more about us? Visit 2general.com »

Keep that module out!

We usually include a local_settings.py file in our Django projects. We use the file whenever some Django settings need to be tweaked according to the environment or specific requirements of individual developers.

It was a challenge to find a good way to exclude that file from being installed in production.


An easier way to change Django cache backend between test cases

In Changing Django cache backend between test cases I showed how to use the Mock library to activate a different cache backend for individual tests.

In the comments for that article, Diederik van der Boor pointed out that the same effect can be achieved in a cleaner way by using a custom “proxy” cache backend.

I took the challenge and created a proxy cache backend and a decorator for switching the effective backend on the fly.


Splitting up settings in Django

By default all Django settings are in one monolithic settings.py file. A single big file is hard to read and hard to maintain.

Django users have found many ways to split up the settings into multiple files, all of them with their pros and cons. In our latest projects, we have developed yet another way, which uses file inclusion instead of importing Python scripts.

The main features of django-split-settings are:

  1. Settings can be split into files and directories.
  2. Files later in the list can modify configurations, for example add or remove apps from INSTALLED_APPS.
  3. The main settings file lists the files that make up the project’s settings.
  4. Files can be marked optional. Optional files can be used to override settings per instance.
  5. Wildcards can be used in file paths.
  6. Maintains support for Django’s runserver auto-reloading.

Changing Django cache backend between test cases

It’s a good practice to run tests for a Django project with a dummy cache backend. This eliminates side effects of one test from affecting the results of other tests.

Here’s how to activate the dummy backend in a Django settings file:

    'default': {
        'BACKEND': 'django.core.cache.backends.dummy.DummyCache'

However, sometimes it’s also necessary to test how an application uses the cache. In this article, we’ll show how to replace the dummy cache with a real cache backend separately for individual test cases.


Selective restore from database backups with Django

Scream by eflon, on Flickr

When things go wrong and you lose your database, backups will help save the day. If the whole production database is corrupted or lost, it’s simple to throw it away and restore it in its entirety from the latest backup.

If data loss caused by a user error has remained unnoticed for some time, valuable data may since have been stored, and restoring a complete backup is not an option. In such cases it’s useful to be able to do a partial restore of one or more tables while keeping the rest of the database.

For these complex cases, I’m going to describe a technique for restoring a subset of the data in one or more relational database tables using Django.