| Age | Commit message (Collapse) | Author |
|
bzr revid: vmt@openerp.com-20130404130704-24vsmczw34cssytd
|
|
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
|
|
They were probably used by some tools. How sad.
bzr revid: vmt@openerp.com-20130212142410-zqdjd8jw3gtvxab0
|
|
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
|
|
half the connections and is not strictly required
Credit to Florent Xicluna for spotting it!
lp bug: https://launchpad.net/bugs/905257 fixed
bzr revid: odo@openerp.com-20130219102610-ll69qaf3zxem1pxf
|
|
to be dead
lp bug: https://launchpad.net/bugs/905257 fixed
bzr revid: odo@openerp.com-20130216011831-5ehi02j5nj6shh8n
|
|
borrow that connection, not before, for obvious performance reasons
bzr revid: odo@openerp.com-20130215161025-mjgmlju3zgs50zk7
|
|
My bad, I did and undid this patch several times
in different manners and ended up commiting the
wrong one.
lp bug: https://launchpad.net/bugs/905257 fixed
bzr revid: odo@openerp.com-20130215151237-3ks21kfhjb2fvl2z
|
|
and earlier
Having the connections automatically reaped by
psycopg2 is not guaranteed to happen all the
time, so we still need to take extra steps
to forece-close them
bzr revid: odo@openerp.com-20130215113751-12kwmfynyt43qs57
|
|
lp bug: https://launchpad.net/bugs/905257 fixed
bzr revid: chs@openerp.com-20130214135227-x6lzy3gj0s75ssmw
|
|
bzr revid: xmo@openerp.com-20121214124310-wfdkhmcwxnyqu30m
|
|
bzr revid: xmo@openerp.com-20121214124243-kvg2cg00k0a4518p
|
|
bzr revid: xmo@openerp.com-20121214123803-6xu2s1ndnoyj4i3e
|
|
bzr revid: rco@openerp.com-20121015100148-pkanx35vr6fqojuj
|
|
bzr revid: xmo@openerp.com-20120924101404-cel6oy1akabbo7id
|
|
bzr revid: vmt@openerp.com-20120206203151-3snkz7usngwtv1xt
|
|
bzr revid: vmt@openerp.com-20120202092634-pylu3098p5c0mays
|
|
bzr revid: vmt@openerp.com-20120202092105-mfufuv97h8zrc2n7
|
|
bzr revid: al@openerp.com-20120201002321-nstmlzxzrcfgev13
|
|
lp bug: https://launchpad.net/bugs/924783 fixed
bzr revid: ronald@therp.nl-20120201113759-wi2kogl2x1lsxk7g
|
|
Warnings are handled with the other logs (and not always sent to stderr),
they also appear under a module __name__ channel instead of py.warn.
The disadvantage is that there is no longer specific warnings,
such as pending deprecation warning or deprecation warning.
bzr revid: vmt@openerp.com-20120125132407-u33idc0qh7ecs1i5
|
|
bzr revid: vmt@openerp.com-20120124111438-730miqdcm3eljgds
|
|
bzr revid: vmt@openerp.com-20120118160305-ucennaoqehjuut1z
|
|
python versions).
bzr revid: vmt@openerp.com-20120118114109-txh1cjv503xautty
|
|
--db_template=my_template, default is template0
bzr revid: nicolas.bessi@camptocamp.com-20120117164940-i3g1zcu49x0g60t5
|
|
bzr revid: florent.xicluna@gmail.com-20120115214214-0rjwn80choc9g0fs
|
|
connection is lost.
bzr revid: florent.xicluna@wingo.ch-20111117093335-6t16181mqt49z7bi
|
|
bzr revid: odo@openerp.com-20110928211326-0e51q7zlw4h2528z
|
|
only per query
bzr revid: odo@openerp.com-20110924015852-9vru7cdsmzbvault
|
|
revision-id: odo@openerp.com-20110714105552-9tgofrjtdgjmgc4b.
Each OpenERP cursor is mapped to a single psycopg2 connexion.
When a cursor is closed, the connexion is pushed back to a
pool and reused later. Now that the 'snapshot isolation' level
is used, the fact we didn't properly commit/rollback a
transaction appears: some 'concurrent' update showed up.
The fix is simple: whenever a cursor is closed, we rollback
any pending operation (which is the expected behavior).
(Furthermore, the connexion is explicitely closed when the
connexion is pushed back but not kept in the pool.)
bzr revid: vmt@openerp.com-20110913143444-s49r7r2h6m00p5s3
|
|
bzr revid: vmt@openerp.com-20110825124711-y2uckmvcoa0arz4h
|
|
In the context of OpenERP transaction, we really need the
'snapshot isolation' level provided by PostgreSQL because
not being able to make repeatable reads within the same
transaction is a very dangerous source of corrupted data,
especially in a very concurrent system.
The performance impact of switching from the default
read_committed level to serializable/repeatable_read level
has been measured and and was not distinguishable from
the standard deviation - so it seems quite acceptable.
User of PostgreSQL 9.1 might want to update to psycopg2
version 2.4.2 or later to properly use the regular
snapshot isolation level, and not the newer, more
expensive serializable level (see comments in Cursor
docstring).
bzr revid: odo@openerp.com-20110714105552-9tgofrjtdgjmgc4b
|
|
bzr revid: vmt@openerp.com-20110713153521-isn9bllnggbxwi0z
|
|
bzr revid: xrg@linux.gr-20110623090357-nazly8vpfnw0iskr
|
|
bzr revid: xrg@linux.gr-20110623090312-afwjqqduqdtex017
|
|
This will be printed along the error message whenever an attempt to use
a closed cursor is made (only in debug_sql log level).
bzr revid: vmt@openerp.com-20110422112417-dbeqq4qm59sr2wvt
|
|
- This is necessary to give a chance to change the config just after importing openerp.
bzr revid: vmt@openerp.com-20110421103125-3lv609wnu3vh2m4f
|
|
- 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
|
|
lp bug: https://launchpad.net/bugs/716715 fixed
bzr revid: vmt@openerp.com-20110308140449-5v883yms1z8dy23k
|
|
- 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
|