Django Readonly Field is a tiny Django library to make sure Django never tries to write certain model fields. and the introduction to the series of articles.

The problem

You are using a Postgresql database to power you Django website, and you’d like to use certain features that make this database great like, say, materialized views, or triggers. In other words, you’re saying that there are some specific fields in some specific tables of your database that are completely OK to read and absolutely not ok to write.

That’s perfect because there’s a property of Django Model Fields that is called “editable” that keeps those fields from being included in Model forms. Yay, problem solved.


You have no control over what the ORM will do. Especially, when you do a, those field will be written to the database (even if they have not changed and especially if they did). If you happen to have a large codebase, it can be tricky to manually audit all of your code (both past and future) to make sure that no one will ever write on this field.

So let’s take a different approach.

The solution

The short answer

Use django-readonly-field. It’s quite young I admit, but it’s tested, it’s simple and I wrote it.

Once you’ve configured what fields you want to be read only, Django will never ever include those field in INSERT and UPDATE queries.

I don’t really want to copy the usage instruction because it’s already in the Readme, but, trust me, it’s dead simple.

The longer answer (a.k.a how does this work ? Is this black magic ?)

In the Era of the Geek, we’re all magicians here, the only difference is that many of us tend to open source our tricks. But the source is not in itself the key to understanding all that takes place here without at least a bit of information.

So, there’s a second article that explain how it works. I might continue the series and explain more things like tests and CI (edit : yay, it’s now published), packaging, scaffolding, docs, etc., depending on the feedback (if any).

Thank you, and stay tuned !