Either use openerp.modules.registry.RegistryManager when the full
new() signature is needed, or use openerp.registry().
Replaced also some pool.get() with pool[] because KeyErrors
are better than AttributeErrors on None.
bzr revid: vmt@openerp.com-20130327111014-2i0hlvpy5y5ku7hm
Previously all _*constraints leaked upstream and
downstream, and were duplicated in all the exported
terms for all modules inheriting from a given model.
bzr revid: odo@openerp.com-20121204082947-tdpiu71ryxzuredb
This patch comes with a related patch on addons which
fixes a lot of cases of terms that were not properly
translated in reports, due to improper use of the
translation system. The addons patch also adds a
lot of missing entries in the POT files.
bzr revid: odo@openerp.com-20121008110946-21984tjvhoy8zkx9
- qweb and Javascript terms extraction now builtin
- all qweb/JS terms are flagged with an extra PO comment:
`openerp-web`, which the web client will use when
loading translations
- the homemade Python/Mako extractor has been removed
and replaced by the default babel Python extractor.
Net result is that we extract less spurious terms, but
keep valid ones, so everything looks great under
the sun.
bzr revid: odo@openerp.com-20121003132659-h5obyl1j7hjo1y2b
The GetText spec says that PO auto-comments indicating
the source location have this form:
#: /path/to/file:lineno
However OpenERP's POT export system defaults to a modified
version of this format with an extra 'type' field:
#: type:/path/to/file:lineno
The babel extractors we use for openerp-web's translations
have the GetText format hardcoded, so it's a good idea
to be more lenient and allow the standards annotations too.
We can use a default 'code' type for such cases.
For openerp-web translations the type does not matter,
as the translations will be directly loaded by the
web engine from the PO files and served in Javascript
to the browser, with no typing needed.
This patch simply avoids failing to parse updated PO files
that will contain standard GetText annotations for the
openerp-web related terms.
bzr revid: odo@openerp.com-20120202143210-05p1w24t6u77cyv8
At a language import (translation files), we want to push a big batch of
translation records into the database. These will need update-or-insert
logic (against existing ones) or even resolution of ir.model.data .
Doing this loop in Python had been slow (invoking 2x read()s, +1 for
ir.model.data, 1 insert or update), triggered the cache (fill and clean
at each iteration).
Instead, follow the old-school db recipe for mass records insertion:
- create a temporary table w/o indexes or constraints
- quickly populate the temp with all records of the batch
(through a dedicated "cursor" object)
- process the table, doing lookups in collective SQL queries (yes, SQL
is all about loops of data processing, efficiently)
- insert all records from temp into ir.model.data
- call (implicitly) all constraints of ir.model.data at the end of that
single query.
This improves performance of translation imports by ~3x at least.
bzr revid: xrg@linux.gr-20110608162059-rfy1vvwp8w66ry0i
- openerp.pooler no longer provides get_db_only, which is a provided by sql_db
- openerp.sql_db does not rely anymore on netsvc, which is goog as it was
making a circular import. The downside is that db_close callers have to clean
also the Agent themselves.
bzr revid: vmt@openerp.com-20110420141407-au0oanwjc0t15vy5
- Some logging code moved from netsvc.py to loglevels.py
- Changed imports to use the new openerp module
- config and netsvc initialization calls move to openerp-server.py
- Moved openerp-server.py outside the old bin directory
- Some imports in tools moved inside the methods to break mutual-dependencies
bzr revid: vmt@openerp.com-20110207125723-ooee7d7ng5elmkso
Vo Minh Thu
Olivier Dony
Niels Huylebroeck
Xavier Morel
Chris Biersbach
Stephane Wirtel
Jigar Amin - OpenERP
Turkesh Patel (Open ERP)
Fabien Pinckaers
Naresh (OpenERP)
P. Christeas
P. Christeas
Antony Lesuisse