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
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
The message worked (ish) for a missing field directly on the model,
but completely broke if the missing field was on an o2m and had the
same name as a field on the model, then it was complete
misinformation.
bzr revid: xmo@openerp.com-20121112084804-zcgtpml3a19uv909
Previous behavior was unspecified and untested - leading to random results
when performing operations on a mix of deleted and ir.rule-filtered records.
The behavior is now clarified and explicitly tested.
One suprising case remains: read() on a deleted record
returns an empty result instead of raising an error,
in order to avoid spurious errors when a client
performs a sequence of search(), read() while
another user is deleting records.
bzr revid: odo@openerp.com-20121109171451-z2m6oqs910103lcz
Otherwise a previous validation (or 2) will poison the cache and the
import itself will fail even though the validation succeeeded (and
importing with no validation would have succeeded), as the orm cache
doesn't take DB rollbacks in account.
bzr revid: xmo@openerp.com-20121109113951-p3qgg6m5g7poay5e
For some obscure reason _validate used to immediately
rollback the current transaction as soon as a constraint
failed anywhere. This is completely incorrect and
violates the transaction abstraction: the responsibility
of creating and closing transactions belongs to the
RPC dispatch layer, or whatever takes its place (e.g. the
test setup/teardown for tests). Rolling back or committing
in the middle of a transaction precludes special
error treatment and can have very bad side effects.
bzr revid: odo@openerp.com-20121029180742-2gw08kobdh7w5njc
When grouping on a date or datetime field, read_group groups by (year, month),
and formats that pair to have a displayable result (as a group title).
This is currently done with strftime and the pattern `%B %Y` (complete word
month, long year), which is problematic as — at best — it uses the server's
locale for its formatting. This means if the server works in an english locale
e.g. russian users are going to see the month name in english, instead of their
own language.
This proposal makes use of `babel.dates.format_date`, which is locale-aware
(and to which a locale can be provided directly) and the locale present in the
request context to format the month, year pair according to the user's
language.
bzr revid: vmt@openerp.com-20121012144634-spaqze7d4jc8l00l