When the `create` or `write` method receives an empty string for a date
or a datetime field, PostgreSQL will fail since this is not an accepted
value for this field type.
We fallback on `None` for falsy values.
opw-1819336
@KangOl : watch out when forward-porting, the signature of
`convert_to_column` has changed in saas-14.
Given the following variables:
* Module A
* Module B
* Model M
* Field X of model M
If module A defines M.X and is installed, an xmlid for this field is
generated in the form of A.field_M_X
Before this commit:
If module B defines M.X as well and is installed after module A, no
xmlid is generated.
This means that if module A is uninstalled, the single xmlid pointing to
M.X will be deleted and thus, the field itself will be deleted as well,
therefore any views from module B referencing M.X will crash.
After this commit:
If module B (or any subsequent modules) define M.X, an xmlid will be
generated in the form of B.field_M_X.
If module A is uninstalled, the xmlid A.field_M_X will be deleted, but
B.field_M_X will remain and thus the field itself won't be deleted.
This system means that for a single actual field, there can be multiple
xmlids, each xmlid sharing the same field, thus the name "shared
fields".
Task ID 38016
Optimize the copy of the cache being made by related fields to compute
themselves. Instead of traversing records data in cache, follow the cache
structure itself and copy everything!
OPW 816125
Log an info when a field is computed and stored, but not all its dependencies
are stored. Also allow to set explicitly `depends` on a field; this is useful
to restrict the dependencies of a related field.
In other words, when a field F depends on a non-stored field G, it also depends
on G's dependencies. This guarantees that whenever a dependency of G is
modified, F will be invalidated and marked to recompute (if necessary).
The transitive closure of dependencies is not computed over stored fields.
Anyway stored fields already trigger the recomputation of their dependent
fields during their recomputation. The performance impact on the loading of a
registry is negligible (less than 1%), and the increase of recomputation
triggers is small (less than 10%).
Assuming that `field.cache_key(record)` is independent from `record.id`,
compute the cache key once for all records, and avoid using `browse` on all
record ids. This makes `get_records` about 20 times faster.
This has a good performance impact on `field.modified_draft()`, which is used
during onchanges for invalidating fields.
Suppose we convert a x2many field `foo_ids` with a many2one sub-field `bar_id`.
The conversion of the values of `bar_id` generates pairs `(id, name)`. Before
this patch, the method `name_get` is invoked on every value, one by one.
Rewrite the code to ensure that `name_get()` is invoked on all values at once.
backport of afef71d6b9
Original commit message:
Let `create` and `write` round monetary field values before sending them to the
database. Pass the values to be written to `field.convert_to_column`, so that
the currency can be retrieved from the values, and the value be rounded.
With this commit, we change the behaviour of the web client with respect
to spaces in char fields. Most of the time, starting and ending spaces
have no value, and worse, make the data not so reliable.
After this commit, field char will trim by default (so, if the user input a
char as ' abc ', the string 'abc' will be sent to the server instead).
Note that this only applies when the value of the field is changed. If
someone open a form view, then switches to edit mode and save, nothing
will change.
This is the desired behavior most of the time. However, in some rare
cases, this is actually harmful. For example, if we trim the
'decimal_point' field, it will not be possible to enter a whitespace as
decimal separator. In those cases, we introduce a new attribute 'trim',
which allow the developer to desactivate that feature.
Prefetching is underused when all fields are traversed one record at a time.
So instead, traverse all records one field at a time. This guarantees batch
prefetching/computation on every field being accessed.
That function is called when computing related fields in onchange mode.
The new implementation makes a direct access to the cache's implementation.
opw-772303
When reading a one2many field, the inverse field of the retrieved lines may
already be assigned in cache to a new record. This can happen during an
onchange. In that case, the algorithm crashes. Let's clean it up!
Raphael Collet