When developing a system that needs to handle time, it is very common to need to track not only “when” something happens, but also “for how long”, for example: event calendars, taxi rides, etc. The most common patterns to solve this problem are start+end and start+duration, but both require two fields in your schema.

Fortunately, PostgreSQL can solve this problem using a range field, a special type of field that encodes the start and end of a numerical series (including time), enabling the use of special functions and operations. The Django framework, trying to be full-feature in relation to PostgreSQL, supports those fields natively.

Did you ever change your mind about your Django database structure? Sometimes you need to create references between models, but for some reason you didn’t use a ForeignKey field, and there are good cases for that, for example: the ID came from a different system, but you decided to have a local copy. On this article I show how to convert it the proper way.

If you want to dockerize a GeoDjango project, the most common method is to use an oficial Python image as its base, and install all GIS dependencies over it, being GDAL the heaviest one, making your final image easily reach the mark of the multi-megabytes. But GDAL is very modular, and most GeoDjango projects can work fine with its basic compilation.

This article shows how to flip that dependency, and use the official minimal GDAL images as a basis, adding the Python/Django structure over it. Also, how to pick a leaner PostGIS image to save even more space on your development environment.