The dsn may contain the connection password of the database when not accessed from a psycopg connection object.
Replace the unfiltered logs to use cxn.dsn avoiding password leakage in logs.
Fixes#1433
- TestCursor subclasses Cursor, and simulates commit and rollback with savepoints
- the registry manages a test mode, in which it only uses the test cursor
- a reentrant lock forces the serialization of parallel requests
bzr revid: rco@openerp.com-20140408151736-j0guy68i2wjexy3d
time.time doesn't guarantee sub-second precision.
Use a uuid1 instead (lower anonymity but higher isolation than uuid4
especially in distributed systems, and we don't care about anonimity for
savepoint names from application servers).
Quote name so first character can be a digit.
bzr revid: xmo@openerp.com-20140220103345-xistzxy17r8j87hf
When a varchar column has a dependence on a view, we cannot change the size in-place,
we need to manually re-create the column with the correct type.
bzr revid: chs@openerp.com-20140217182045-qor70r3gb0fch2ki
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
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
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
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
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