- 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
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
Raphael Collet
Christophe Simonis
Kersten Jeremy
Antony Lesuisse
Xavier Morel
Vo Minh Thu
Olivier Dony
Ronald Portier
nicolas.bessi@camptocamp.com
Florent Xicluna
Florent Xicluna
P. Christeas