The definition of a computed field is the same as that of a regular field, except that a compute attribute is added to specify the name of the method to use for its computation.

Their similarity can be deceptive, since computed fields are internally quite different from regular fields. Computed fields are dynamically calculated at runtime, and unless you specifically add that support yourself, they are not writable or searchable.

The computation function is dynamically calculated at runtime, but the ORM uses caching to avoid inefficiently recalculating it every time its value is accessed. So, it needs to know what other fields it depends on. It uses the @depends decorator to detect when its cached values should be invalidated and recalculated.

Write support can be added by implementing the inverse function. This uses the value assigned to the computed field to update the origin fields. Of course, this only makes sense for simpler calculations; nevertheless, there are still cases where it can be useful. In our example, we make it possible to set the book release date by editing the Days Since Release computed field. The search attribute is optional; if you don't want to make the compute field editable, you can skip it.

It is also possible to make a non-stored computed field searchable by setting the search attribute to the method name (similar to compute and inverse). Like inverse, search is also optional; if you don't want to make the compute field searchable, you can skip it.

However, this method is not expected to implement the actual search. Instead, it receives the operator and value used to search on the field as parameters, and is expected to return a domain with the replacement search conditions to use. In our example, we translate a search of the Days Since Release field into an equivalent search condition on the Release Date field.

The optional store=True flag stores the field in the database. In this case, after being computed, the field values are stored in the database, and from there on, they are retrieved like regular fields instead of being recomputed at runtime. Thanks to the @api.depends decorator, the ORM will know when these stored values need to be recomputed and updated. You can think of it as a persistent cache. It also has the advantage of making the field usable for search conditions, including sorting and grouping by operations, without the need to implement the search method.

The compute_sudo=True flag is to be used in cases in which the computations need to be done with elevated privileges. This might be the case when the computation needs to use data that may not be accessible to the end user.