« Changelog History


ZODB v3.5.0 Release Notes

  • 🚀 Release date: 31-Aug-2005

    🚀 Following is combined news from internal releases (to support ongoing 🚀 Zope3 development). These are the dates of the internal releases:

    • 3.5a7 11-Aug-2005
    • 3.5a6 04-Aug-2005
    • 3.5a5 19-Jul-2005
    • 3.5a4 14-Jul-2005
    • 3.5a3 17-Jun-2005
    • 3.5a2 16-Jun-2005
    • 3.5a1 10-Jun-2005

    💾 Savepoints

    • 🗄 (3.5.0) As for deprecated subtransaction commits, the intent was that making a savepoint would invoke incremental garbage collection on Connection memory caches, to try to reduce the number of objects in cache to the configured cache size. Due to an oversight, this didn't happen, and stopped happening for subtransaction commits too. Making a savepoint (or doing a subtransaction commit) does invoke cache gc now.

    • (3.5a3) 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 the loadBefore() 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.5a4) 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.

    ZEO client cache

    • (3.5a6) 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 are deprecated

    • 🚚 (3.5a4) Subtransactions are deprecated, and will be removed in ZODB 3.7. Use savepoints instead. Savepoints are more powerful, and code using subtransactions does not mix well with code using savepoints (a subtransaction commit forces all current savepoints to become unusable, so code using subtransactions can hurt newer code trying to use savepoints). 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 optional optimistic 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()
    • (3.5a4) Internal uses of subtransactions (transaction commit() or abort() passing a true argument) were rewritten to use savepoints instead.

    Multi-database

    • 👍 (3.5a1) Preliminary support for persistent cross-database references has been added. See ZODB/cross-database-references.txt for an introduction.

    Tools

    • (3.5a6, 3.5a7) 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 revised trace.txt and cache.txt.

    • (3.5a5) Collector #1846: If an uncommitted transaction was found, fsrecover.py fell into an infinite loop.

    🏁 Windows

    • (3.5a6) 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.

    ThreadedAsync.LoopCallback

    • (3.5a5) This once again physically replaces Python's asyncore.loop function with its own loop function, because it turns out Zope relied on the seemingly unused LoopCallback.exit_status global, which was removed in the change described below. Python's asyncore.loop is again not invoked, so any breakpoints or debugging prints added to that are again "lost".

    • (3.5a4) This replaces Python's asyncore.loop function with its own, in order to get notified when loop() is first called. The signature of asyncore.loop changed in Python 2.4, but LoopCallback.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's asyncore.loop() instead of replacing it entirely (so, for example, debugging prints added to Python's asyncore.loop won't be lost anymore).

    FileStorage

    • (3.5a4) Collector #1830. In some error cases when reading a FileStorage index, the code referenced an undefined global.

    • (3.5a4) Collector #1822. The undoLog() and undoInfo() methods were changed in 3.4a9 to return the documented results. Alas, some pieces of (non-ZODB) code relied on the actual behavior. When the first and last arguments are both >= 0, these methods now treat them as if they were Python slice indices, including the first index but excluding the last index. This matches former behavior, although it contradicts older ZODB UML documentation. The documentation in ZODB.interfaces.IStorageUndoable was changed to match the new intent.

    • (3.5a2) The _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".

    BTrees

    • (3.5.a5) 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.5a4) Collector 1831. The BTree minKey() and maxKey() methods gave a misleading message if no key satisfying the constraints existed in a non-empty tree.

    • (3.5a4) Collector 1829. Clarified that the minKey() and maxKey() methods raise an exception if no key exists satsifying the constraints.

    • 🚚 (3.5a4) The ancient convert.py script was removed. It was intended to convert "old" BTrees to "new" BTrees, but the "old" BTree implementation was removed from ZODB years ago.