In my latest blog post, I delve into the world of computed fields and how they can simplify your models, automate computations, and give a performance boost to your Django applications. Computed fields allow you to dynamically calculate values based on other fields within your models, eliminating the need for manual updates and ensuring data consistency.
With the Django Computed Fields package, computed fields become first-class citizens in your database. These fields are turned into real database fields, enabling you to access, search, and filter them just like any other field. During the model’s save process, the associated computation method is invoked, and the result is seamlessly written to the database.
My blog post goes beyond the basics and explores advanced features, such as dependencies on local fields and foreign key relationships. I provide practical code examples to illustrate how you can leverage computed fields to enhance your Django models and automate complex calculations effortlessly.
I prolly should give you some feedback on the article (disclaimer - I am the author of the package).
First thank you for writing this up, it gives a nice basic summary of what is possible with the package.
Still I think there are some aspects I would have phrased differently or should be emphasized, before trying to sell the package to people as an easy to use drop-in:
Imho you should at least mention, that the package does denormalization. This is important, as denormalization comes with big drawbacks like data duplication and therefore synchronization issues. While it is true that the package tries to hide most of that for casual usage, you will face the issue once you start using bulk methods.
The examples are somewhat poor and might lure people into thinking, that it is the right tool for doing simple calculations, nope it is not. Here it would be good to point out, that there are non-redundant pattern like annotated fields or python properties (or the yet to come db calculated fields). Those should always be tried first before going down the denorm rabbit hole. I know that it is tricky to give the right picture with examples (I also have lousy examples in the docs), but to properly inform your readers about the purpose of this lib, it should at least be mentioned in the text. Denormalization should always be treated as a last resort, not as an early easy drop-in.
The part with the refresh_from_db notion is somewhat messed up. The method will update values on model instances in your memory, thus might overload changed values, that got not yet saved to the db. Thats no different with computed fields, they will contain the db value on first retrieval. If you hold on to an instance with a computed field, and do other changes that might affect that field, then your instance gets outdated and you can get the new value from the db with refresh_from_db.
There are some limitations with computed fields, that prolly should be mentioned as well (like it should not be used with db expressions).
