Merge lp://qastaging/~openerp-dev/openobject-server/7.0-remove-duplicate-logging-xmo into lp://qastaging/openobject-server
| Status: | Needs review |
|---|---|
| Proposed branch: | lp://qastaging/~openerp-dev/openobject-server/7.0-remove-duplicate-logging-xmo |
| Merge into: | lp://qastaging/openobject-server |
| Diff against target: |
750 lines (+242/-47) (has conflicts) 15 files modified
openerp/addons/base/i18n/fr.po (+101/-19) openerp/addons/base/i18n/hu.po (+15/-6) openerp/addons/base/i18n/mn.po (+11/-0) openerp/addons/base/i18n/nl.po (+11/-2) openerp/addons/base/i18n/ro.po (+17/-5) openerp/addons/base/i18n/tr.po (+15/-0) openerp/netsvc.py (+5/-1) openerp/osv/orm.py (+18/-3) openerp/osv/osv.py (+0/-3) openerp/report/report_sxw.py (+2/-0) openerp/service/workers.py (+7/-1) openerp/sql_db.py (+3/-7) openerp/tests/addons/test_impex/ir.model.access.csv (+1/-0) openerp/tests/addons/test_impex/models.py (+10/-0) openerp/tests/addons/test_impex/tests/test_load.py (+26/-0) Text conflict in openerp/addons/base/i18n/fr.po Text conflict in openerp/addons/base/i18n/hu.po Text conflict in openerp/addons/base/i18n/mn.po Text conflict in openerp/addons/base/i18n/nl.po Text conflict in openerp/addons/base/i18n/ro.po Text conflict in openerp/addons/base/i18n/tr.po |
| To merge this branch: | bzr merge lp://qastaging/~openerp-dev/openobject-server/7.0-remove-duplicate-logging-xmo |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| OpenERP Core Team | Pending | ||
|
Review via email:
|
|||
Description of the change
Part of fp-desired effort to cut down on redundant or non-actionable `error` logging (including exceptions): exceptions thrown from psycopg will often be logged twice, and even when expected and caught will be logged *anyway* by a logging layer in sql_db itself, surrounding the query execution code.
This logging was removed, with its actual feature (ensuring the SQL query itself is logged) moved to dispatch_rpc, by logging the error's `.cursor.query` attribute if there is one.
Just in case, if the query execution fails but no `query` is set on the exception's `cursor` (e.g. psycopg2 blew up during parameter adaptation so no query's been executed), manually add the (non-adapted) query to the cursor for logging (can give hints as to what was being done).
Unmerged revisions
- 4834. By Xavier (Open ERP)
-
[FIX] don't log-and-raise in @check
- 4833. By Xavier (Open ERP)
-
[IMP] Remove exception logging in sql_db.py
Redundant with the same feature in dispatch_rpc: exceptions triggered
by a cr.execute may find themselves logged twice, with and without
useful stack (logging.exception will only display the stack between
the place where the exception was thrown and where it's logged, so in
sql_db only a single — useless — level of stack will be displayed).The logging in sql_db was most likely so the failed SQL could be
displayed in cases where the exception message does not display/format
it. This can be handled at a higher level by using `.cursor.query` on
psycopg2.Error objects.Just in case the query isn't set on the cursor (e.g. if the error was
triggered while adapting arguments?), explicitly set the query on the
cursor if none is in sql_db.
