On uninstalling, if external ids are associated to an unexisting field, we do not try to delete the field (as it doesnt exist) and we remove the orphan external ids
bzr revid: dle@openerp.com-20140221104908-7ytdg6xkxaza05o4
- introduce a new xmlid_ set of function with a single cache and raise_on_not_found=False
- implement backward compatible api based on the new one
bzr revid: al@openerp.com-20140129030256-pqj3eay9vf4w2m14
In `init` mode, a record can still be filled with multiple record
nodes with the first node being in a data@noupdate="1" and the other
nodes without @noupdate attribute but this won't be the case anymore in
`update` mode
bzr revid: fme@openerp.com-20131216144304-2e8b9xvoks2fvlj9
Just like for the uninstallation process, records should be
deleted with last created first, as an attempt to reverse
the operations in the right order (to avoid errors due to
dependencies between records).
bzr revid: odo@openerp.com-20131118125640-kdo3t34uszqggu13
It's completely broken in case of optional parameters
e.g. (ir.translation)._get_source, as a call with the optional
parameter won't be matched by a clear without, and the other way
around. This becomes even more problematic in the website branch as
_get_source now has *two* optional parameters (source and res_id).
After discussion with odo and discovery that in multiprocess only the
current node will use any granularity (other nodes not only clear all
of the current method cache, but all caches of all models), simplify
cache clearing, ignore parameters and just blow the current method's
cache entirely.
bzr revid: xmo@openerp.com-20131024132956-4tl3prum8za47igy
The _auto_init call in ir.model.fields creation will not
do it because it happens before the insertion of the model
in the registry. It will only work for later addition of
fields.
bzr revid: odo@openerp.com-20130730114645-185kbupcrbtnv1tf
Either use openerp.modules.registry.RegistryManager when the full
new() signature is needed, or use openerp.registry().
Replaced also some pool.get() with pool[] because KeyErrors
are better than AttributeErrors on None.
bzr revid: vmt@openerp.com-20130327111014-2i0hlvpy5y5ku7hm
This is needed so the uninstall process can simply go through
the installed data by using the ir_model_data entries in reverse
order (when ordered by IDs), so that parents are deleted before
children.
bzr revid: vmt@openerp.com-20130321133202-igea1vxlszfpk6pe
Some important points to consider:
- signaling should be done after any schema alteration (including module [un]installation),
service registration (e.g. reports)
- the changes need to be committed to the database *before* signaling, otherwise an
obvious race condition occurs during reload by other workers
- any call to restart_pool() must be considered a possible candidate for
signaling, and the 2 above conditions must be checked
The number of explicit calls was reduced by forcing the signaling at the end of
Registry.new() in case `update_module` was passed as True. In that situation
we always want to signal the changes - so all the redundant signaling calls
can be centralized. We can also assume that the relevant changes have already
been committed at that point, otherwise the registry update would not
have worked in the first place.
This means that there is no need for explicit signaling anymore everytime
`restart_pool` is called with `update_module=True`.
Some missing cr.commit() and explicit signaling calls were added or
moved to the right place. As a reminder: signaling must be done
*after* committing the changes, and usually *after* reloading the
registry on the current worker.
bzr revid: odo@openerp.com-20130301143203-e2csf5pkllwhmwqs