Loading time was mesured on the loading of a second database (identical to the
first one), i.e. by passing -d xx,yy on the command line, using cProfile. The
databases were installed with sale, mrp, and the crm.
The cProfile code is commited as part of this patch and should be removed (or
maybe guarded by some command-line flag) (just as the commenting-out of the
cron startup).
The patch was also applied on top of the trunk-simple-table-stats-vmt branch
which provides SQL queries counters.
Results indicate that the number of SQL queries are reduced from about 2100 to
27. Loading time is reduced from 1.3s to 0.26s (i.e. improved by 5).
Changes:
All calls to ir_model_fields to fetch manual (custom) fields are done in a
single call (prior to instanciate all models).
Checks for empty module descriptions are not done unless we are in init or
update mode. (The behavior was the opposite, which was probably a mistake).
Some calls to ir_translation, passing en_US because there was no lang in the
context, are not done anymore.
The improved time is also a result of a change in the decimal_precision module
where precision_get fetches all digits/applications instead of one at a time
(and thus implements its own caching instead of relying on
openerp.tools.ormache).
bzr revid: vmt@openerp.com-20121211105954-lwgs5js7yw3tzghs
Nota: If we replace sequence signaling for cache invalidation with pg
listen/notify in the future, we will use the same mechanism for more accurate
cron timing.
bzr revid: al@openerp.com-20121209170447-zs0k3jazokylwvar
As of 7.0, RNG validation is not possible for form views
that have a version attribute equal to "7.0", due to the
allowed usage of HTML syntax mixed with the regular OpenERP
view syntax. RNG validation is still enabled for regular
form views (@version missing or less than "7.0"), and for
all other views types.
Validation of 7.0 form views should be improved with the
addition of an assertion-based schema, still to be done.
The above is also complemented with an explicit call to fields_view_get()
during view installation, in order to immediately verify
that the updated view hierarchy does not cause any
issue when loaded along with its related views (i.e
parent and siblings, for inheriting views).
In addition to that, fields_view_get() will now only
consider loading views that belong to modules that have
already been loaded. This avoids a lot of validation errors
during a module update operation, which runs on top of
an existing database with all previous views visible,
even those whose module is not loaded yet.
bzr revid: odo@openerp.com-20120611122758-qcw9xdhupl24busq
The auto_install flag means that the module will be automatically
installed as soon as all its dependencies are satisfied.
It does *not* mean that the module will be automatically installed
upon database creation. It can be used for that purpose by
setting it on a module that has no dependencies however.
bzr revid: odo@openerp.com-20120611103653-l7x0xxdqo4wixjvl
Remove foreign key references.
Remove sql constraint .
Remove workflow activity and transition based on deleted cascade.
Drop ir model fields columns and drop table.
bzr revid: atp@tinyerp.com-20120309124753-c4yzeoij5p2fmhgg
- pass around the assertion_report to the YAML importer
- removed TestReport, which was identical to assertion_report
- assertion_report is simpler (no more severity level)
- use the report to log a greppable sentence when some test failed.
Previously the runbot had to grep for a Traceback which was an
unreliable technique (e.g. an exception can be purposefuly
generated as part of a test and the associated traceback
visible in the logs). Now it can grep
"At least one test failed when loading the modules".
bzr revid: vmt@openerp.com-20120302110227-nqrl7i46ju28ntdr
- moved a few YAML tests to unittest2 for demonstration purpose
- changed --test-disable to --test-enable (and swapped its meaning)
bzr revid: vmt@openerp.com-20120301134608-szuktuj8imdhmn0r
This is essential to have the proper behavior for
timestamps: on the database side we exclusively
store UTC data (no DST issues, etc.) as naive
timestamps (to prevent Postgres from messing with them).
Inside OpenERP server/addons we work again with
pure UTC data (much simpler), and only render
them according to the user's timezone when they
are displayed in the user interface or rendered
in a PDF report.
lp bug: https://launchpad.net/bugs/918257 fixed
bzr revid: odo@openerp.com-20120220105943-v3m0i50phrurt8x6
The previous behavior gave the precedence to zipped
modules, without any apparent reason, and this is
sub-optimal for several reasons:
1. The default is to have regular modules, not
zipped modules, so looking first for a regular
module is more efficient.
2. Keeping a zipped module next to a regular
module with the same name is not a documented
or supported feature.
3. Even if you were relying on this behavior
having the extracted module take precedence
is more practical: you could simply extract
the zipped module to test a quick fix.
We have another issue related to this feature
because the code looking for zipped modules
escapes the addons paths chroot and goes
up to the filesystem root looking for a zip
module at each step. This is described in
bug 928376 and a fix for it should follow.
lp bug: https://launchpad.net/bugs/928376 fixed
bzr revid: odo@openerp.com-20120208173932-pwhz53vxxdzbo8ja
`auto_installable`. An auto-installable module is a module automatically
installed by the OpenERP server as soon as its dependencies are
satisfied, without explicit user action.
bzr revid: vmt@openerp.com-20120126164049-smrcvrojy0b1z6f8
Having the sequence number living outside the module itself
causes various problems at initialization when modules are
missing (e.g. if creating a database with `base` only).
It is also cleaner to have the module sequence in the
module manifest, like other module metadata.
A corresponding commit in the addons project adds the
`sequence` field in the manifest of all modules who
have a non-default sequence (the main apps).
bzr revid: odo@openerp.com-20120107041745-tik3iu1b2qs4ym85
* If icon is present in descriptor file, use that path
* Else try to find #{module}/static/src/img/icon.png
* Else fallback on /base/static/src/img/icon.png
bzr revid: xmo@openerp.com-20111209122803-elwonegpl8kut7pf
this should be now fixed by making sure that --withou-demo flag (or its absence)
is taken care of, and setting the base module demo field.
Normally the demo state of a module should have a ripple
effect on all modules depending on it. This might prove
not enough in this case and require some more testing.
bzr revid: vmt@openerp.com-20111117162824-yqswv6yk7bmiyj4s
- update_module was defined as config[init] or config[update]
- this means it is a mutable dictionary
- the code testing update_module is actually mutating
config[init] and config[update]...
- now update_module is really a True or False value.
bzr revid: vmt@openerp.com-20111117100608-0n8o99slgk42kiiv
We'll now have a BaseModel with 3 subclasses, AbstractModel,
TransientModel and Model. Model is for regular models,
TransientModel for automatically-vacuumed models, and
AbstractModel for common superclasses meant to be
inherited by other models only, and not directly used.
bzr revid: odo@openerp.com-20110923124525-jfzk55dk3ban2ps2
When two requests arrive simultanously for the same uninitialized db,
the first request starts the db initialization, but the second one
immediately gets the partially uninitialized registry (actually just
created, so generally completely uninitialized), leading to an access
error in later code (as soon as a registry object is accessed).
Add a GRML (Global RegistryManager Lock) to ensure the RegistryManager
*never* returns a partially initialized registry.
The current implementation is simple (just lock all RegistryManager
methods before they manipulate registries), but overly broad. This is
an area which might be optimizable if there are perf/responsivity
issues (e.g. each Registry instance could have a lock, and the
RegistryManager would grab the instance's, allowing the inititlization
of registry A not to block registry B from being returned in heavily
concurrent uses).
However this is not an issue in multiprocessing scenarios, which are
being planned for the near future. So for now, being correct is
probably the best idea.
bzr revid: xmo@openerp.com-20110916075227-0zutzlxn2dcd94c4
- added Microsoft specific header for webdav.
- serve WSGI handlers with werkzeug when available.
- effectively use WSGI instead of netsvc HTTP stack.
bzr revid: vmt@openerp.com-20110914104300-n0l3dnmdu3jau7w2
This is necessary to preserve the model loading order
as defined in the module. This was broken when the
metaclass was introduced to make the explicit model
constructor call optional.
One consequence is that the order in which the classes
are declared in the module really defines their
initialization order, even if the constructors are
later called explcitly in a different order.
This latter case should be fairly rare, and easy to
fix too - simply putting the class declaration in the
right order.
bzr revid: odo@openerp.com-20110826161736-lgnpurtbcqtbseey
After the recent change to make module install
atomically (code *and* data), we ran into issues
when installing a new module indirectly triggers
code of a not-yet-loaded-but-installed module,
via its data that is already in the database
(e.g. worflows or reports modified by this module
within another module, that now refer to its
code).
To avoid this, we now make sure that we only
install new modules on top of a consistent system
(code *and* data), by loading all installed or
'to upgrade' modules *before* starting to install
new ones.
lp bug: https://launchpad.net/bugs/809168 fixed
bzr revid: odo@openerp.com-20110712133343-unf610k23fa6d3pk
- make it more explcicit in osv_pool that afreshly instanciated object is added to the pool
- osv_pool.init_set() is called just once with False, so
no need to check if it is the first time it is called or
if is called with True
- and rename it in do_parent_store as it is what it does.
bzr revid: vmt@openerp.com-20110526210532-a8i91shptz5h4k48
- removed unnecessary call to openerp.modules.db.initialize() in openerp/service/web_services.py
as the pooler.restart_pool() call just next after is already doing it.
- made the try/finally section bigger in openerp/modules/loading.py, to inlcude
the first cr.execute.
- abstracted the test to check if a database is initialized.
- removed unnecessary "if cr:" as the cr is nevertheless used after that.
bzr revid: vmt@openerp.com-20110517091822-pjtw6sc1s5assbr5
- added some comments
- the "updating modules list" log appears only when actually updating the list
- similar code to read the module descriptor file is combined
- default values for some descriptor entries are given only once
- in particular, the default version is always 0, instead of 0 when
reading a descriptor for migration and 1.0 when writing its value in
database.
bzr revid: vmt@openerp.com-20110511103455-lqezcrjf2996j7mc
- pass the report argument to xml_import
- allow .sql in demo
- noupdate is True for both init and demo
- the pathname given to convert_csv_import is different
but the way it is processed in convert_csv_import should
make it alright.
bzr revid: vmt@openerp.com-20110510125242-ig74vtich2g3bjhc
Vo Minh Thu
Christophe Simonis
Antony Lesuisse
Arnaud Pineux
Xavier Morel
Fabien Pinckaers
Olivier Dony
Stephane Wirtel
Jigar Amin - OpenERP
Mayur Maheshwari (OpenERP)
Thibault Delavallée
Atul Patel (OpenERP)
Minh Tran
Raphael Collet