Due to the multi-company record rule on gamification.goal,
each access to the Goals menu and each opening of the
Messaging menu (thus calling get_serialised_gamification_summary())
is extremely slow (with several thousands goals/users).
Adding auto_join to the user_id FK on goals makes it much
faster. However it causes crashes when reading the table
because the _order of gamification.goal uses `create_date`,
which becomes ambiguous after the auto_join with res_users.
Solving this can be done by re-implementing _read_flat()
in the ORM using the internal Query object, as in search(),
which takes care of fully-qualifying all column names.
Until this is fixed, a simple workaround is to use
start_date in the _order instead of collision-prone `create_date`.
If any missing or partially incorrect values cause
an exception other than a psycopg2 error, we should
still catch it, rollback that record and report
the error, rather than letting bubble and fail
without any feedback to the user.
Fixes#1485
When a record is created, the magic fields (id, create_date,...) are first removed from the vals as the user should not set a value for these.
However if a value for this is given in default value (e.g. defined in an ir.value), the creation would crash (sql error : column specified more than once) as the magic column would be added again.
These parameters are (or should be) irrelevant for
a search_count(), and they could actually break the
result or make it significantly slower (e.g applying
`order` on large tables).
This fixes a performance regression introduced by
0f43032b.
We could also raise an error offset/limit are
passed in combination with count, but that seems
unnecessary.
Also switched to "SELECT count(1)" for the count
query, as it is simpler and just as fast.
We'd get the same perf with * or any constant value,
as in "SELECT count('me in')", but let's keep it
simple ;-)
At rev 84e9a67cdf a check to avoid the creation of ir.model.relation for custom modules was added. The condition is not correct as based on the string instead of the field name. We do not have access to column name at this level but the the m2m relation table do start with x_ for custom fields (see __init__ method).
orm: do not try to create ir.model.relation for custom m2m as self._module is either empty (for custom models), either the one of the last inheriting module (which is wrong). The field should be removed manually and should not be impacted by the uninstallation of modules. The removal of the relation table can be done when removing manually the custom field (see rev 6af3193).
ir.model: when removing a model, drop the table with the CASCADE instruction. This will remove left constraints from remaining m2m tables.
This means that dropping a table (either manually removing a custom model or uninstalling a module) will not drop the relation table for a custom m2m field. This is not ideal but better than the previous behaviour (which was to fail the DROP TABLE instruction and keep the table with a few columns and unconsistent data).
fixes#595
In the case where a property for the company exists but has no related record (e.g. in case of type m2o with no defined value), not setting a value to this field for a new record would create a new property (as browse_null is not an instance of browse_record)
_read_flat: remove duplicated fields in read call
get many2one: as False is instance of int, check the value of x first to avoid calling a name_get with a list of False
When we were reading twice a m2o field where at least one result is null, the first call to name_get would set the value to False instead of None and then accepted by the filter 'isinstance(x, (int,long))'
The get() method of m2o function fields is used for 2 different things:
- call the function defining the m2o
- get the name_get representation of the value
Until this pathc, only the first case was handled, resulting to a useless
recomputation of the field when reading it.
function fields for other records in the same model. Previously all function fields in the
current model were not computed for some reason not provided by the history.
We therefore compute effective store_ids on which the various trigerred
function fields will be computed again. Those ids are the ids given
in the store_get storage variable minus the deleted ones.
The active_test flag is meant for search(),
but when passed to search_read() it was also
propagated to the read() call.
This has little consequence normally because
read() ignores this flag, but it can have
side-effects when reading x2m fields or
function fields. They are likely to call
search() somewhere downstream, still with
the propagated active_test flag, while
it should not be applied anymore.
Ultimately dropping this flag could be
done by read() in all cases, but changing
search_read() is less likely to block
exotic cases where the flag was passed
on purpose. Moving it to read() could
be done as a later step.
This comparison is flawed by nature but can be a useful
shortcut sometimes. It was using wrong boundaries and
would also loop for operators not explicitly handled
by the code (there was no `else` block). It is still
not possible to handle time zone conversions properly,
so this is only an experimental feature.
bzr revid: odo@openerp.com-20140404133827-5owdendpsr083a17
If the o2m field linked to the o2m is stored on a different table (eg: model with _inherit), previous request would crash as the field do not exists in the '_table' sql table
bzr revid: mat@openerp.com-20140327111241-klftr0s8v8i68nxp
If the o2m field linked to the o2m is stored on a different table (eg: inherit), previous request would crash as the field do not exists in the '_table' sql table
bzr revid: mat@openerp.com-20140324162130-fyotk8vqmkha43eb
Christophe Simonis
Denis Ledoux
Martin Ambroz
Olivier Dony
Samus CTO
dhr-odoo
Martin Trigaux
Alexandre Fayolle
Mohammed Shekha
kevin wang
Jeremy Kersten
Oliver Laurent
Thibault Delavallée
Christophe Simonis
jba