When a string value is assigned to a selection field expecting integers, the
value simply rejected. In such a case, convert the value to an integer before
validating it.
When a record fields are prefetched, the currently accessed record is
prefetched as well as PREFETCH_MAX (=1000) minus currenly accessed
records.
Since 439fa826 the id field was thought as "prefetched" but was not,
which caused that in an onchange, we would have a prefetching as follow
for 1200 records:
- get records 1-1000
- get record 1001 (1001-1200 INTERSECTION 1-999 (id) + 1001 (current))
- get record 1002 (1002-1200 INTERSECTION 1-999 (id) + 1002 (current))
- get record 1003 (1003-1200 INTERSECTION 1-999 (id) + 1003 (current))
- ...
- get record 1200 (1200 INTERSECTION 1-999 (id) + 1200 (current))
So we would do 201 queries instead of 2 when prefetching the records.
The added test without this change failed the query count with:
"AssertionError: 284 not less than or equal to 5 : admin"
opw-1837548
opw-1837552
closes#24326
Assume a custom field F is defined on model 'res.partner'. The setup of F may
silently fail because of missing stuff. In that situation, setting up the
field inherited from F on model 'res.users' should also silently fail.
To reproduce the bug, install Invoicing, create a related custom field F on
'res.partner' with 'property_account_position_id.active', and install another
module. Setting up F after loading module 'base' will fail because the field
'property_account_position_id' does not exist yet. The error is not caught by
the inheritance of F on model 'res.users', and the installation crashes.
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.
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
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.
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!
The command does not need to remove existing relations, as there is no relation
yet on new records. This saves one query per many2many field with that command
in a `create`.
An update by a list of commands is now guaranteed to have at most three SQL
queries to update the relation, whatever the number of commands and records.
The record cache is indexed by `(field, record_id, key)`, where `key` depends
on the environment. The key is either `(cr, uid, context)` or `(cr, uid)`,
depending on whether the field's value is context-dependent. As most fields
are not context-dependent, this should avoid some cache prefetching when
swiching context.
Make `RecordCache` work on a single record only, and implement a mapping from
field names (only) to values.
Also add explicit methods on `RecordCache` to wrap special behavior in cache,
and simplify all special values as a wrapper for a getter function.
The record cache may contain regular and special values. Modify `RecordCache`
so that only methods ending with `_value` check for regular values. The
dictionary methods considers both regular and special values as equivalent.
name in record._cache # test if cache has a value
iter(record._cache) # iterate on values
record._cache[name] # get value
record._cache.get(name) # get value or default
record._cache.has_value(name) # test if cache has a regular value
record._cache.get_value(name) # get regular value or default
The x2many "create" command is now like: `(0, ref, vals)`, where `ref` is an
arbitrary reference that may be used to identify a new line in the relation.
The reference is returned in a similar command by the method `onchange`.
`onchange` now supports self-modifying x2many fields.
Now that we're closer to switching to P3 for good, these helpers have
outlived their usefulness, and mostly add noise.
All remaining dict.iter*() or dict.view*() must be converted to the
normal keys(), values() or items() calls.
Whenever the result is likely to be used for more than the scope of a
loop, or when the dict needs to be modified during iteration, the calls
must be wrapped in a ``list()``, to protect the new P3 semantics.
Those cases are very exceptional.
Also removed some dead code or improved the API to remove unnecessary
conversions.
* unichr -> pycompat (builtin removed from Python 3, ``chr`` has
become unicode-aware)
* Psycopg2 bytea values (binary fields) are returned as memoryviews in
P3 but buffers in P2
* Both bytes and (text) strings are conventionally iterable in
P3 (they have a __iter__ method), so fix up the exclusion pattern
for flatten
* remove references to basestring & unicode (use relevant pycompat
helpers)
* remove some str calls (either entirely or replaced by relevant
helper, either text or native)
* use better API to avoid unnecessary conversions
* remove some XML declarations in views
* StringIO removed from stdlib, replace with io
* try to correctly handle BytesIO/StringIO (one is for bytes the other
is for text)
* fix base64: Python 3 removed bytes-encoding and bytes-bytes
codecs (via #encode) so replace all calls to str.encode('base64'),
also b64encode is a bytes->bytes conversion so attempt to properly
handle that
issue #8530
Raphael Collet