Aaron O. Ellis

Recently, I wanted to make use of the Postgres COPY methods within Django. Most people recommended django-postgres-copy, however, as of April 2024, the package only supports psycopg2 and Django 4.2. It also makes use of a temporary table, whereas I felt comfortable enough with copying the values directly to their destination table.

The Django developers have worked hard to integrate Postgres full text search into the web framework’s ORM. Unfortunately, there are few quirks with the system, especially when working with JSON model fields. In this post, we’ll discuss those issues and how to work around them.

If you’re querying a table with a small number of rows in Postgres, your query will most likely use a “sequential scan”, which scans the entirety of the table to find your result. This is true even when tables have an index for the field or fields you’re querying.

Schemas are a shockingly underappreciated feature of relational databases. With minimal overhead, they enable segmentation and isolation of tables within a database.

If you are interested in using schemas with Postgres, I recommend starting with the official documentation’s fantastic introduction. Although I will reiterate some of the introduction below, I will mainly focus on the exceptional behavior and issues that arise when using schemas.

The django-filter package adds a quick way to add URL parameter driven filtering to existing Django database models. For example, take the following model:

We can then use django-filter to quickly create a FilterSet class that wraps the above database model:

The Python datetime.utcnow() classmethod is harmful and should be replaced with datetime.now(timezone.utc).

What makes utcnow() so dangerous? Although the function gives the correct time in the UTC timezone, the returned datetime does not include a timezone.