- 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
Raphael Collet
Olivier Dony
Antony Lesuisse
Xavier Morel
Stephane Wirtel