When loading the registry without any module installation/upgrade, models are
set up once instead of twice. In other cases, models are always set up before
installations/upgrades.
Loading views for custom models from module data files was not possible because
custom models and fields were introduced into the registry after all modules
were loaded. As a consequence, the view architecture did not pass the checks.
This patch takes a different approach: custom models and fields are loaded
early on in the registry, so that views can be validated. The trick is to take
special care of relational custom fields: we skip them if their comodel does
not appear in the registry. This allows to install and upgrade modules that
create/modify custom models, fields and views for them.
This simple optimization in load_marked_modules() avoids unnecessary calls to
load_module_graph(). This provides a small speedup, and avoids confusing log:
some module updates were making it look like the registry was loaded 5 times
instead of once.
If the server was started without -i or -u and
happened to initialize a fresh database,
auto-installed modules that depend
on `base` only would stay in status "to install"
without actually being installed (until the next
installation round was triggered).
This was of little consequence in 7.0, but causes
a crash in 8.0.
Fixes#953
It's broken (though easy to fix) and not very useful, if third parties want to
create databases asynchronously they can handle the asynchronicity on the
client-side (an HTTP request is easy to make asynchronously after all) and
call the synchronous `create_database()`.
fixes#1137, after a fashion
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
Add a loglevel 25 to log some INFO to runbot
Add timers for loading and testing
Silence empty test suite
ir_logging use relative pathname, warning this doesnt work for --addons-path modules yet.
Since 4ec71c74d1, migration scripts
are not executed at module install anymore.
As this behavior was missused as "init" scripts (see [1]), this
commit re-add this possiblity via hooks.
There are 3 hooks that can be declared in the manifest file:
- pre_init_hook: called before module installation
- post_init_hook: called after module installation
- uninstall_hook: called before module uninstallation
Like the "post_load" manifest option, the values for these hooks
must be a string containing the name of a method available at the
module root.
The signatures of these functions are:
- (cr) for pre_init_hook
- (cr, registry) for post_init_hook and uninstall_hook
[1] https://bugs.launchpad.net/openobject-server/+bug/1314680
When the registry is updating, the view verification only validates the views
from initialized modules. Not taking the current module allow update of views
that have also an inherited view in the same module. The verification of the base view
must not try to apply the old inherited view against it as it may not be applicable
anymore.
After module update, we re-validate all the views of this module. This is needed because
a module can declare two (or more) inherited views that are correct when applyed alone,
but not when combined with others.
bzr revid: chs@openerp.com-20140418141550-7b57b1xl4fx0rgqq
remove deprecated zipfile support
add preload_registry option when server is running
allow registries to be used in contruction in test mode
add a rollback test case for http tests
add a phantomjs helper
bzr revid: al@openerp.com-20140209004005-p5pwym4sqc23vw5b
In some rare cases the dependencies have changed, and modules that depend on an uninstalled module
will not be processed on the first pass.
bzr revid: odo@openerp.com-20130909095004-n1dp2w5wnlb36742
When --test-enable is used, it is expected that test output is visible,
thus using log-level INFO is natural.
On the down side you lose the nice blue hint that tests did actually
run when --log-level test was given.
bzr revid: vmt@openerp.com-20130326155844-83e2tcqokvblr0ln
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
Raphael Collet
Denis Ledoux
Olivier Dony
Xavier Morel
Antony Lesuisse
Christophe Simonis
Yann Papouin
Christophe Simonis
chm@openerp.com
Fabien Meghazi
jke-openerp
Denis Ledoux
Samus CTO (OpenERP)
Quentin (OpenERP)
Vo Minh Thu