ZODB v3.4.1 Release Notes
-
๐ Release date: 09-Aug-2005
๐ Following are dates of internal releases (to support ongoing Zope 2 ๐ development) since ZODB 3.4's last public release:
- 3.4.1b5 08-Aug-2005
- 3.4.1b4 07-Aug-2005
- 3.4.1b3 04-Aug-2005
- 3.4.1b2 02-Aug-2005
- 3.4.1b1 26-Jul-2005
- 3.4.1a6 19-Jul-2005
- 3.4.1a5 12-Jul-2005
- 3.4.1a4 08-Jul-2005
- 3.4.1a3 02-Jul-2005
- 3.4.1a2 29-Jun-2005
- 3.4.1a1 27-Jun-2005
๐พ Savepoints
(3.4.1a1) When a savepoint is made, the states of objects modified so far are saved to a temporary storage (an instance of class
TmpStore
, although that's an internal implementation detail). That storage needs to implement the full storage API too, but was missing theloadBefore()
method needed for MVCC to retrieve non-current revisions of objects. This could cause spurious errors if a transaction with a pending savepoint needed to fetch an older revision of some object.๐ (3.4.1a5) The
ISavepoint
interface docs said you could roll back to a given savepoint any number of times (until the transaction ends, or until you roll back to an earlier savepoint's state), but the implementation marked a savepoint as invalid after its first use. The implementation has been repaired, to match the docs.(3.4.1b4) Collector 1860: use an optimistic savepoint in ExportImport (there's no possiblity of rollback here, so no need to insist that the data manager support rollbacks).
ZEO client cache
- (3.4.1b3) Two memory leaks in the ZEO client cache were repaired, a
major one involving
ZEO.cache.Entry
objects, and a minor one involving empty lists.
Subtransactions
(3.4.1a5) Internal uses of subtransactions (transaction
commit()
orabort()
passing a true argument) were rewritten to use savepoints instead. Application code is strongly encouraged to do this too: subtransactions are weaker, will be deprecated soon, and do not mix well with savepoints (when you do a subtransaction commit, all current savepoints are made unusable). In general, a subtransaction commit done just to free memory can be changed from::transaction.commit(1)
to::
transaction.savepoint(True)
That is, make a savepoint, and forget it. As shown, it's best to pass
True
for the optionaloptimistic
argument in this case: because there's no possibility of asking for a rollback later, there's no need to insist that all data managers support rollback.In rarer cases, a subtransaction commit is followed later by a subtransaction abort. In that case, change the initial::
transaction.commit(1)
to::
sp = transaction.savepoint()
and in place of the subtransaction abort::
transaction.abort(1)
roll back the savepoint instead::
sp.rollback()
FileStorage
(3.4.1a3) Collector #1830. In some error cases when reading a FileStorage index, the code referenced an undefined global.
(3.4.1a2) Collector #1822. The
undoLog()
andundoInfo()
methods were changed in 3.4a9 to return the documented results. Alas, some pieces of (non-ZODB) code relied on the actual behavior. When thefirst
andlast
arguments are both >= 0, these methods now treat them as if they were Python slice indices, including thefirst
index but excluding thelast
index. This matches former behavior, although it contradicts older ZODB UML documentation. The documentation inZODB.interfaces.IStorageUndoable
was changed to match the new intent.(3.4.1a1) The
UndoSearch._readnext()
method now returns the transaction size as the value of the "size" key. Thanks to Dieter Maurer for the patch, from http://mail.zope.org/pipermail/zodb-dev/2003-October/006157.html. "This is very valuable when you want to spot strange transaction sizes via Zope's 'Undo' tab".
ThreadedAsync.LoopCallback
(3.4.1a6) This once again physically replaces Python's
asyncore.loop
function with its own loop function, because it turns out Zope relied on the seemingly unusedLoopCallback.exit_status
global, which was removed in the change described below. Python'sasyncore.loop
is again not invoked, so any breakpoints or debugging prints added to that are again "lost".(3.4.1a1) This replaces Python's
asyncore.loop
function with its own, in order to get notified whenloop()
is first called. The signature ofasyncore.loop
changed in Python 2.4, butLoopCallback.loop
's signature didn't change to match. The code here was repaired to be compatible with both old and new signatures, and also repaired to invoke Python'sasyncore.loop()
instead of replacing it entirely (so, for example, debugging prints added to Python'sasyncore.loop
won't be lost anymore).
๐ Windows
- (3.4.1b2) As developed in a long thread starting at
http://mail.zope.org/pipermail/zope/2005-July/160433.html
there appears to be a race bug in the Microsoft Windows socket
implementation, rarely visible in ZEO when multiple processes try to
create an "asyncore trigger" simultaneously. Windows-specific code in
ZEO/zrpc/trigger.py
changed to work around this bug when it occurs.
Tools
(3.4.1b1 thru 3.4.1b5) Collector #1847. The ZEO client cache tracing and simulation tools weren't updated to work with ZODB 3.3, and the introduction of MVCC required major reworking of the tracing and simulation code. These tools are in a working state again, although so far lightly tested on just a few applications. In
doc/ZEO/
, see the heavily revisedtrace.txt
andcache.txt
.(3.4.1a6) Collector #1846: If an uncommitted transaction was found, fsrecover.py fell into an infinite loop.
DemoStorage
- (3.4.1a1) The implementation of
undoLog()
was wrong in several ways; repaired.
BTrees
(3.4.1a6) Collector 1843. When a non-integer was passed to a method like
keys()
of a Bucket or Set with integer keys, an internal error code was overlooked, leading to everything from "delayed errors" to segfaults. Such cases raise TypeError now, as intended.(3.4.1a4) Collector 1831. The BTree
minKey()
andmaxKey()
methods gave a misleading message if no key satisfying the constraints existed in a non-empty tree.(3.4.1a3) Collector 1829. Clarified that the
minKey()
andmaxKey()
methods raise an exception if no key exists satsifying the constraints.