Merge lp:~openerp-dev/openobject-server/trunk-view-dependencies-xmo into lp:openobject-server
Status: | Needs review |
---|---|
Proposed branch: | lp:~openerp-dev/openobject-server/trunk-view-dependencies-xmo |
Merge into: | lp:openobject-server |
Diff against target: |
307 lines (+153/-59) 3 files modified
openerp/modules/registry.py (+2/-1) openerp/osv/orm.py (+147/-58) openerp/tools/sql.py (+4/-0) |
To merge this branch: | bzr merge lp:~openerp-dev/openobject-server/trunk-view-dependencies-xmo |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Olivier Dony (Odoo) | Pending | ||
OpenERP Core Team | Pending | ||
Review via email: mp+205765@code.launchpad.net |
Description of the change
Fixes conflict between inheriting from a view and depending on one:
* A module A defines a view a
* A module B defines a view b, which depends on (uses, e.g. via a join) a
* A module C inherits from (and alters) a
There is no interdependency between B and C. If C is loaded after B it will cause a new call to a.init(), which will DROP VIEW a CASCADE, which will drop b. The system ends up with view b missing even though the corresponding module (and model) are installed. There are cases of this happening in standard OpenERP modules e.g. the view crm_partner_
If sale_crm is installed after crm_partner_
Rejected fix method:
A consideration was to use Postgres's dependency analysis after view creation to infer view dependencies and correctly handle their reloading, this was deemed to magical and overly complex (getting dependencies between views without false positives is not trivial).
Fix method: explicit declaration of dependencies and a special view-creation method which attempts to explicitly drop and re-init dependents on the fly. The default path will use a non-cascading DROP VIEW and in case of error fall back on a cascading drop view with an error message logged.
Unmerged revisions
- 5071. By Xavier (Open ERP)
-
[FIX] correctly handle drop failure (by forcing)
Drop failure can be caused by unregistered dependent views, or some other type
of dependent. If the case is encountered, log it and fallback on the old
behavior of forcing everything to drop using CASCADE.Looked into diag object (>9.3) for possibly more informative error message,
but nothing is available outside of the exception's base info messages. - 5070. By Xavier (Open ERP)
-
[ADD] View class for dependency handling
- 5069. By Xavier (Open ERP)
-
[IMP] move _name validation to create_instance
- 5068. By Xavier (Open ERP)
-
[IMP] minor style improvements
- 5067. By Xavier (Open ERP)
-
[REF] extract special attributes handling from create_instance
not sure this should be a module-level global thing though
Initial strategy of a method call turns out to not work right (I think) for more than 1 level of dependency, there may be views init-ed multiple times and ordering can be completely broken.
Replaced the whole concept by a specific Model subclass, the developer provides the view's query (as a method or a class-level attribute) and the class can then cleanly handle destructions and recreations in case of reinit.