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).
When droping a column, remove also the relation table in case of custom m2m field.
The relation table needs to be dropped otherwise an unremovable constraint to the targetted table is kept (and anyway is not needed anymore).
A squashed merge is required as the conversion of the apiculture branch from
bzr to git was not correctly done. The git history contains irrelevant blobs
and commits. This branch brings a lot of changes and fixes, too many to list
exhaustively.
- New orm api, objects are now used instead of ids
- Environements to encapsulates cr uid context while maintaining backward compatibility
- Field compute attribute is a new object oriented way to define function fields
- Shared browse record cache
- New onchange protocol
- Optional copy flag on fields
- Documentation update
- Dead code cleanup
- Lots of fixes
When uninstalling a module, remove the ir.model.constraint after removing the non-model records and before fields and model definition.
Without this fix, some constraint would be removed too early allowing to have broken relations and data left from removed module.
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