When the sequence value is 1 it means that either:
- the registry was just instantiated, so there is no
reason to reload it immediately, the real checks will
start at next request
- the db was just created with new sequences set to 1,
so there has been no change to reload
In both cases there is no good reason to reload the
registry, and it is actually a performance killer,
especially for cron workers that keep iterating on
the list of databases.
bzr revid: odo@openerp.com-20131011100313-4bud8e9xq2afp9z7
auto=True reports are looked up in the database for each rendering, so they do
no have to be in the report registry any longer.
auto=False reports will register themselves but at this point
they can be updated to use the new `parser` XML attribute.
bzr revid: vmt@openerp.com-20130322153955-s6nyux2pyez6c01w
The pooljobs and scheduled_cron_jobs stuff was only used to
delay the processing of cron jobs until after the registry
was fully loaded. However this is already the case because
RegistryManager.new() only sets the flag at the end of the
init step.
The flag was named `registry.cron` but simply meant that the
registry was fully loaded and ready, so it is simpler to
rename it to `registry.ready`.
In multiprocess mode this flag is enterily irrelevant
so there is no need to selectively set it to True or
False. `registry.ready` is simpler.
bzr revid: odo@openerp.com-20121221133751-h4x670vblfr3d09e
The setting/clearing of the tracking were not done
consistently, causing log messages that appeared
to come from one database while coming from another
one or none at all.
The tracker is now set at the earliest points
of request handling as possible:
- in web, when creating WebRequests (dbname, uid)
- at RPC dispatching in server (uid)
- at cron job acquisition in CronWorker (dbname)
- at Registry acquisition in RegistryManager (dbname)
The tracker is cleared at the very entrance of
the request in the WSGI `application`, ensuring
that no logging is produced with an obsolete
db name. (It cannot be cleared at the end of
the request handling because the werkzeug
wrapper outputs more logging afterwards)
bzr revid: odo@openerp.com-20130301182510-1fqo9o8di0jw95b5
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
The setting/clearing of the tracking were not done
consistently, causing log messages that appeared
to come from one database while coming from another
one or none at all.
The tracker is now set at the earliest points
of request handling where we can:
- in web client, when creating WebRequests (dbname, uid)
- at RPC dispatching in server (uid)
- at cron job acquisition in CronWorker (dbname)
- at Registry acquisition in RegistryManager (dbname)
The tracker is cleared at the very entrance of
the request in the WSGI `application`, ensuring
that no logging is produced with an obsolete
db name. (It cannot be cleared at the end of
the request handling because the werkzeug
wrapper outputs more logging afterwards)
bzr revid: odo@openerp.com-20130301120744-jfitcmze2jldecod
The case where no constraint existed at all was not working,
and after fixing it, the ORM started to re-create the same
constraints multiple times for some modules. This was for
models that are split within a module (such as res.users in
base, which is made of several small classes): all the
partial models were going through _auto_init instead
of only the final one - doing useless extra work.
Unfortunately establishing the FK happens before the
XML data files are loaded, so a number of FK and
NOT NULL constraints failed to apply due to missing
tables/records. base.sql had to be extended a bit
to cover these cases in a minimalist fashion
bzr revid: odo@openerp.com-20121217214645-av9n003yzterhujw
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
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
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
- 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