In 5efac22043 and
1cf5723835 the computation
of the decimal precision of float fields was modified to
reuse a random cursor from the request environments.
Environment.envs is a WeakSet, subject to unpredictable
garbage collections.
This could cause hard-to-diagnose problems by executing
a SELECT query in a cursor that is supposed to be
otherwise idle and untouched.
As an example, this could cause a transaction start in a
cursor that was just committed/rolled back,
and was waiting for another operation to complete.
One such case happened semi-randomly during a module
installation triggered from the web client, where the request
cursor is committed and waiting for the registry
initialization done with a different cursor,
in the middle of _button_immediate_function()
After the registry initialization, the request cursor is
used again to determine the next action (ir.actions.todo),
and this could cause a TransactionRollbackError if the
request cursor was used during the initialization.
Using a new cursor every time is much safer, simpler,
and will not cause any significant performance hit,
because it will usually grab an available connection
from the connection pool, rather than create a new one.
Fixes opw-649151
When linking a record into a `one2many` relation with command `(4, rid)`, a
query checks whether the record is already linked to the current record id:
SELECT 1 FROM {inv_table} WHERE id={rid} AND {inv_field}={id}
where `inv_field` is the name of the inverse field, and `inv_table` is the
table where this field is stored.
The query is wrong if the inverse field is inherited, because the `rid` does
not belong to the table `inv_table`.
The test has been replaced by a plain ORM access:
rec = obj.browse(cr, SUPERUSER_ID, rid)
if int(rec[inv_field]) != id:
...
This fixes#4685.
When ordering results on a many2one fields, results are ordered by
order of the target model. The code was wrongly assuming that this
`_order` attribute only contains `_classic_read` fields (that can be
directly read from the table in database). Now correctly generate the
"ORDER BY" clause using the current table alias.
`res.users` can now be sorted by name.
In version 8.0, postgresql's pg_size_pretty function is used
(http://www.postgresql.org/docs/9.4/static/functions-admin.html) when
getting the size of a binary field when reading if `bin_size`
or `bin_size_[col_name]` is set in the context.
So in 8.0 the size of a binary field get units bytes, kB, MB, GB and TB
which was not taken into account. e.g: '5.3 GB'.
This fix uses the size of the string to choose to differenciate the two.
e.g: '10000 bytes' (the longest size) will be returned directly, but
for something longer the human size of the content length will be
returned.
There is a corner case if a file is shorter than 12 bytes but
it is an enough of a small scenario with small implications that it is
deemed acceptable.
closes#7485
opw-644085
In 7.0, a field overriding an inherited model would overwrite all the
previously set field attributes. In v8 the new API allow us to keep
previous attribute, and only overwrite attributes of our wish.
Following the commit 7b1ef708 (october 2014) an old api field overriding
could conserve previous attributes values in some cases (if the new value
is falsy (None, "", 0, False, (), {}, [], ...) when it should not. It
was partly an optimization to diminish the size of orm registries
dictionaries to save memory (this patch has been tested with all odoo
modules and added +/- 3M).
This commit (proposed by rco) should overwrite falsy value (so the
behavior of v7 for old api fields overwritting is re-introduced) and
get back the behavior of old api in V7.
closes#7035
opw-639712
Thamks to parent commit, `request.env` doesn't raise `AttributeError`
anymore for requests without session bound to a database.
This exception was bubbling up to `digits` property (and `__getattr__`)
This reverts commit 49cb46fb78.
This reinstate commit eeedd2d9f5.
This reverts commit eeedd2d9f5.
This revision introduces an issue more serious than the ones
it fixes. This is no longer possible to receive an email
aimed a sale.order thread with catchall.
To reproduce the issue:
- Create a new sale order
- Send a message in the thread to the customer
- Reply to the mail received in the customer mailbox
- Traceback, AttributeError: digits
opw-640370
The computation of property `digits` was creating a new cursor to call the
function that determines digits. This technique is fragile because the current
cursor may have pending updates that the new cursor will not see.
The issue was discovered by Cécile Tonglet (cto). She observed an infinite
loop during a database migration, and a traceback inside the loop showed the
presence of the `digits` property. This change fixes the infinite loop issue.
`function` fields are fully copied via `copy.copy()`.
`copy.copy()` *do not* call `__init__` after object creation; then
restore the state via `__setstate__()` or by updating `__dict__` or via
`setattr()` when the object uses `__slots__`.
As `__init__` is not called, the newly created object does not have any
`_args` attribute. This lead to a recursive call of `__getattr__ when
`copy.copy` check the existance of `__setstate__` attribute.
When break this loop by forbidding explicitly by checking the attribute
name accessed (We cannot check the presence of `_args` in `__dict__`
because we uses `__slots__`).
See http://bugs.python.org/issue5370Fixes#6037
opw:633109
The computed value of parameter digits is no longer stored into fields and
columns; instead the value is recomputed everytime it is needed. Note that
performance is not an issue, since the method `get_precision` of model
'decimal.precision' is cached by the orm. This simplifies the management of
digits on fields and saves about 300Kb per registry.
The mappings model._all_columns takes quite some memory (around 2MB per
registry) because of the numerous dictionaries (one per model) and inefficient
memory storage of column_info. Since it is deprecated and almost no longer
used, it can be computed on demand.
For public-facing HTML content provided by the user,
`<style>` tags and `style` attributes should be stripped
automatically, as they can easily be abused to deface
pages for abusive users and spammers.
<style> tags were already stripped, the optional `strip_style`
for fields.html enables the automatic stripping of style
attributes.
This is opt-in because custom style attributes are still
desirable in trusted HTML fields.
The implementation was based on the ill-defined method `same_parameters()` that
compares arguments based on a heuristic. Instead, we now create a new column
and check whether it is equivalent to `self` by comparing the arguments
returned by `to_field_args()`. If that is the case, `self` is reused instead
of the new column.
The code refactoring also fixes the column reuse which was broken by the
introduction of the parameter `compute` in commit 9333c62. Indeed, with that
parameter, `same_parameters()` always returned False, since old-api columns do
not have that parameter by default. The parameter has been renamed to
`_computed_field`, and is no longer passed for creating columns.
When overriding a field defined as a function field, the field must either
create a corresponding column that is not a fields.function (if stored), or
have no corresponding column (if not stored).
In a workflow context (for instance, in the invoice workflow),
context is not passed.
Therefore, relying on the 'recompute' key being the context
in order to not recompute the fields does not work with Workflows.
It leads to huge performance issues,
as fields are recomputed recursively (instead of sequentially)
when several records are implied.
For instance, when reconciling several invoices with one payment
(100 invoices with 1 payment for instance),
records of each invoice are recomputed uselessly in each workflow call
(for each "confirm_paid" method done for each invoice).
With a significant number of invoices (100, for instance),
it even leads to a "Maximum recursion depth reached" errror.
closes#4905
For models using a datetime field as name (hr.attendance for instance), the user timezone wasn't applied in the display name.
Therefore, in the breadcrumb, the datetime was different than in the form if the user had another timezone than UTC.
The old-api model._all_columns contains information about model._columns and
inherited columns. This dictionary is missing new-api computed non-stored
fields, and the new field objects provide a more readable api...
This commit contains the following changes:
- adapt several methods of BaseModel to use fields instead of columns and
_all_columns
- copy all semantic-free attributes of related fields from their source
- add attribute 'group_operator' on integer and float fields
- base, base_action_rule, crm, edi, hr, mail, mass_mailing, pad,
payment_acquirer, share, website, website_crm, website_mail: simply use
_fields instead of _all_columns
- base, decimal_precision, website: adapt qweb rendering methods to use fields
instead of columns
Clarify the semantics of field attributes:
- field.store is True when the field is actually stored in the database;
- field.column is the column corresponding to field or None.
The various field definitions correspond to:
- new-style stored field: field.store and field.column
- new-style non-stored field: not field.store and not field.column
- old-style regular field: field.store and field.column
- old-style function field: not field.store and field.column
This is a memory optimization: instead of setting all attributes on all
instances, set them with their default value on the class, and only set
specific ones on instances. This reduces the memory footprint of around 14Mb
per registry with modules crm, sale, purchase and stock installed.
This is a memory optimization: it reduces the memory footprint of each
registry. We have observed a reduction of 10Mb on a database with modules crm,
sale, purchase, stock.
This fixes issue #2146. The inverse of a one2many field can be an inherited
field (_inherits). In that case, we cannot read its value with a simple
database query. Instead, we let the related field read it, but for performance
considerations we disable the prefetching of other fields.
When reading a one2many field, the inverse mapping of the lines (matching m2o -> lines of corresponding record) was instantiating each line and then triggering the prefect of fields.
To improve the performances, the inverse mapping is done in sql to avoid triggering the prefetching.
Raphael Collet
Olivier Dony
Christophe Simonis
Nicolas Lempereur
Laetitia Gangloff
Denis Ledoux
Martin Trigaux
Martin Ambroz