[Zodb-checkins] SVN: ZODB/branches/3.6/NEWS.txt Try to add missing
NEWS entries. Not sure this is complete.
Tim Peters
tim.one at comcast.net
Sun Dec 4 20:37:45 EST 2005
Log message for revision 40529:
Try to add missing NEWS entries. Not sure this is complete.
Deleted news from ZODBs 3.5 and earlier; the news file was
getting ridiculously large.
Changed:
U ZODB/branches/3.6/NEWS.txt
-=-
Modified: ZODB/branches/3.6/NEWS.txt
===================================================================
--- ZODB/branches/3.6/NEWS.txt 2005-12-04 21:46:34 UTC (rev 40528)
+++ ZODB/branches/3.6/NEWS.txt 2005-12-05 01:37:45 UTC (rev 40529)
@@ -1,10 +1,11 @@
-What's new in ZODB3 3.6b4?
+What's new in ZODB3 3.6b5?
==========================
Release date: 06-Nov-2005
Following is combined news from internal releases (to support ongoing
Zope3 development). These are the dates of the internal releases:
+- 3.6b4 04-Dec-2005
- 3.6b3 06-Nov-2005
- 3.6b2 25-Oct-2005
- 3.6b1 24-Oct-2005
@@ -109,7 +110,7 @@
PersistentMapping
-----------------
-- (3.6b3) The ``PersistentMapping`` makes changes by a ``pop()`` method call
+- (3.6b4) ``PersistentMapping`` makes changes by a ``pop()`` method call
persistent now.
- (3.6a1) The ``PersistentMapping`` class has an ``__iter__()`` method
@@ -148,6 +149,8 @@
- (3.6b3) Thanks to Stephan Richter for converting many of the doctest
files to ReST format. These are now chapters in the Zope 3 apidoc too.
+- (3.6b4) Several misspellings of "occurred" were repaired.
+
Development
-----------
@@ -164,2918 +167,9 @@
has a script that expects to import it from there. ZODB's ``mkzeoinst``
script was rewritten to invoke the ``mkzeoinst`` module.
-
-What's new in ZODB3 3.5.1b3?
-============================
-Release date: DD-MMM-2005
-
-Following is combined news from internal releases (to support ongoing
-Zope3 development). These are the dates of the internal releases:
-
-- 3.5.1b3 DD-MMM-2005
-- 3.5.1b2 07-Sep-2005
-- 3.5.1b1 06-Sep-2005
-
-Build
------
-
-- (3.5.1b2) Re-added the ``zeoctl`` module, for the same reasons
- ``mkzeoinst`` was re-added (see below).
-
-- (3.5.1b1) The ``mkzeoinst`` module was re-added to ZEO, because Zope3
- has a script that expects to import it from there. ZODB's ``mkzeoinst``
- script was rewritten to invoke the ``mkzeoinst`` module.
-
-
-What's new in ZODB3 3.5.0?
-==========================
-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.
-
-
-What's new in ZODB3 3.4.2a1?
-============================
-Release date: DD-MMM-2005
-
-Following are dates of internal releases (to support ongoing Zope 2
-development) since ZODB 3.4's last public release:
-
-- 3.4.2a1 DD-MMM-2005
-
-Savepoints
-----------
-
-- (3.4.2a1) 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.
-
-PersistentMapping
------------------
-
-- (3.4.2a1) The ``PersistentMapping`` class has an ``__iter__()`` method
- now, so that objects of this type work well with Python's iteration
- protocol. For example, if ``x`` is a ``PersistentMapping`` (or
- Python dictionary, or BTree, or ``PersistentDict``, ...), then
- ``for key in x:`` iterates over the keys of ``x``, ``list(x)`` creates
- a list containing ``x``'s keys, ``iter(x)`` creates an iterator for
- ``x``'s keys, and so on.
-
-BTrees
-------
-
-- (3.4.2a1) Collector 1873. It wasn't possible to construct a BTree or Bucket
- from, or apply their update() methods to, a PersistentMapping or
- PersistentDict. This works now.
-
-
-What's new in ZODB3 3.4.1?
-==========================
-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 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.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()`` or
- ``abort()`` 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 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()
-
-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()`` 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.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 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.4.1a1) 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).
-
-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 revised
- ``trace.txt`` and ``cache.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()`` and ``maxKey()`` 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()`` and ``maxKey()``
- methods raise an exception if no key exists satsifying the constraints.
-
-
-What's new in ZODB3 3.4?
-========================
-Release date: 09-Jun-2005
-
-Following is combined news from the "internal releases" (to support
-ongoing Zope 2.8 and Zope3 development) since the last public ZODB 3.4
-release. These are the dates of the internal releases:
-
-- 3.4c2 06-Jun-2005
-- 3.4c1 03-Jun-2005
-- 3.4b3 27-May-2005
-- 3.4b2 26-May-2005
-
-Connection, DB
---------------
-
-- (3.4b3) ``.transaction_manager`` is now a public attribute of
- IDataManager, and is the instance of ITransactionManager used by the
- data manager as its transaction manager. There was previously no way
- to ask a data manager which transaction manager it was using. It's
- intended that ``transaction_manager`` be treated as read-only.
-
-- (3.4b3) For sanity, the ``txn_mgr`` argument to ``DB.open()``,
- ``Connection.__init__()``, and ``Connection._setDB()`` has been renamed
- to ``transaction_manager``. ``txn_mgr`` is still accepted, but is
- deprecated and will be removed in ZODB 3.6. Any code that was using
- the private ``._txn_mgr`` attribute of ``Connection`` will break
- immediately.
-
-Development
------------
-
-- (3.4b2) ZODB's ``test.py`` is now a small driver for the shared
- ``zope.testing.testrunner``. See the latter's documentation
- for command-line arguments.
-
-Error reporting
----------------
-
-- (3.4c1) In the unlikely event that ``referencesf()`` reports an unpickling
- error (for example, a corrupt database can cause this), the message it
- produces no longer contains unprintable characters.
-
-Tests
------
-
-- (3.4c2) ``checkCrossDBInvalidations`` suffered spurious failures too often
- on slow and/or busy machines. The test is willing to wait longer for
- success now.
-
-
-What's new in ZODB3 3.4b1?
-==========================
-Release date: 19-May-2005
-
-What follows is combined news from the "internal releases" (to support
-ongoing Zope 2.8 and Zope3 development) since the last public ZODB 3.4
-release. These are the dates of the internal releases:
-
-- 3.4b1 19-May-2005
-- 3.4a9 12-May-2005
-- 3.4a8 09-May-2005
-- 3.4a7 06-May-2005
-- 3.4a6 05-May-2005
-- 3.4a5 25-Apr-2005
-- 3.4a4 23-Apr-2005
-- 3.4a3 13-Apr-2005
-- 3.4a2 03-Apr-2005
-
-
-transaction
------------
-
-- (3.4a7) If the first activity seen by a new ``ThreadTransactionManager`` was
- an explicit ``begin()`` call, then synchronizers registered after that (but
- still during the first transaction) were not communicated to the
- transaction object. As a result, the ``afterCompletion()`` methods of
- registered synchronizers weren't called when the first transaction ended.
-
-- (3.4a6) Doing a subtransaction commit erroneously processed invalidations,
- which could lead to an inconsistent view of the database. For example, let
- T be the transaction of which the subtransaction commit was a part. If T
- read a persistent object O's state before the subtransaction commit, did not
- commit new state of its own for O during its subtransaction commit, and O
- was modified before the subtransaction commit by a different transaction,
- then the subtransaction commit processed an invalidation for O, and the
- state T read for O originally was discarded in T. If T went on to access O
- again, it saw the newly committed (by a different transaction) state for O::
-
- o_attr = O.some_attribute
- get_transaction().commit(True)
- assert o_attr == O.some_attribute
-
- could fail, and despite that T never modifed O.
-
-- (3.4a4) Transactions now support savepoints. Savepoints allow changes to be
- periodically checkpointed within a transaction. You can then rollback to a
- previously created savepoint. See ``transaction/savepoint.txt``.
-
-- (3.4a6) A ``getBeforeCommitHooks()`` method was added. It returns an
- iterable producing the registered beforeCommit hooks.
-
-- (3.4a6) The ``ISynchronizer`` interface has a new ``newTransaction()``
- method. This is invoked whenever a transaction manager's ``begin()`` method
- is called. (Note that a transaction object's (as opposed to a transaction
- manager's) ``begin()`` method is deprecated, and ``newTransaction()`` is
- not called when using the deprecated method.)
-
-- (3.4a6) Relatedly, ``Connection`` implements ``ISynchronizer``, and
- ``Connection``'s ``afterCompletion()`` and ``newTransaction()`` methods now
- call ``sync()`` on the underlying storage (if the underlying storage has
- such a method), in addition to processing invalidations. The practical
- implication is that storage synchronization will be done automatically now,
- whenever a transaction is explicitly started, and after top-level
- transaction commit or abort. As a result, ``Connection.sync()`` should
- virtually never be needed anymore, and will eventually be deprecated.
-
-- (3.4a3) Transaction objects have a new method, ``beforeCommitHook(hook,
- *args, **kws)``. Hook functions registered with a transaction are called
- at the start of a top-level commit, before any of the work is begun, so a
- hook function can perform any database operations it likes. See
- ``test_beforeCommitHook()`` in ``transaction/tests/test_transaction.py``
- for a tutorial doctest, and the ``ITransaction`` interface for details.
- Thanks to Florent Guillaume for contributing code and tests.
-
-- (3.4a3) Clarifications were made to transaction interfaces.
-
-Support for ZODB4 savepoint-aware data managers has been dropped
-----------------------------------------------------------------
-
-- (3.4a4) In adding savepoint support, we dropped the attempted support for
- ZODB4 data managers that support savepoints. We don't think that this will
- affect anyone.
-
-ZEO
----
-
-- (3.4a4) The ZODB and ZEO version numbers are now the same. Concretely::
-
- import ZODB, ZEO
- assert ZODB.__version__ == ZEO.version
-
- no longer fails. If interested, see the README file for details about
- earlier version numbering schemes.
-
-- (3.4b1) ZConfig version 2.3 adds new socket address types, for smoother
- default behavior across platforms. The hostname portion of
- socket-binding-address defaults to an empty string, which acts like
- INADDR_ANY on Windows and Linux (bind to any interface). The hostname
- portion of socket-connection-address defaults to "127.0.0.1" (aka
- "localhost"). In config files, the types of ``zeo`` section keys
- ``address`` and ``monitor-address`` changed to socket-binding-address,
- and the type of the ``zeoclient`` section key ``server`` changed to
- socket-connection-address.
-
-- (3.4a4) The default logging setup in ``runzeo.py`` was broken. It was
- changed so that running ``runzeo.py`` from a command line now, and without
- using a config file, prints output to the console much as ZODB 3.2 did.
-
-ZEO on Windows
---------------
-
-Thanks to Mark Hammond for these ``runzeo.py`` enhancements on Windows:
-
-- (3.4b1) Collector 1788: Repair one of the new features below.
-
-- (3.4a4) A pid file (containing the process id as a decimal string) is
- created now for a ZEO server started via ``runzeo.py``. External programs
- can read the pid from this file and derive a "signal name" used in a new
- signal-emulation scheme for Windows. This is only necessary on Windows,
- but the pid file is created on all platforms that implement
- ``os.getpid()``, as long as the ``pid-filename`` option is set, or
- environment variable ``INSTANCE_HOME`` is defined. The ``pid-filename``
- option can be set in a ZEO config file, or passed as the new ``--pid-file``
- argument to ``runzeo.py``.
-
-- (3.4a4) If available, ``runzeo.py`` now uses Zope's new 'Signal' mechanism
- for Windows, to implement clean shutdown and log rotation handlers for
- Windows. Note that the Python in use on the ZEO server must also have the
- Python Win32 extensions installed for this to be useful.
-
-Tools
------
-
-- (3.4a4) ``fsdump.py`` now displays the size (in bytes) of data records.
- This actually went in several months go, but wasn't noted here at the time.
- Thanks to Dmitry Vasiliev for contributing code and tests.
-
-FileStorage
------------
-
-- (3.4a9) The ``undoLog()`` and ``undoInfo()`` methods almost always returned
- a wrong number of results, one too many if ``last < 0`` (the default is
- such a case), or one too few if ``last >= 0``. These have been repaired,
- new tests were added, and these methods are now documented in
- ``ZODB.interfaces.IStorageUndoable``.
-
-- (3.4a2) A ``pdb.set_trace()`` call was mistakenly left in method
- ``FileStorage.modifiedInVersion()``.
-
-ZConfig
--------
-
-- (3.4b1) The "standalone" release of ZODB now includes ZConfig version 2.3.
-
-DemoStorage
------------
-
-- (3.4a4) Appropriate implementations of the storage API's ``registerDB()``
- and ``new_oid()`` methods were added, delegating to the base storage. This
- was needed to support wrapping a ZEO client storage as a ``DemoStorage``
- base storage, as some new Zope tests want to do.
-
-BaseStorage
------------
-
-- (3.4a4) ``new_oid()``'s undocumented ``last=`` argument was removed. It
- was used only for internal recursion, and injured code sanity elsewhere
- because not all storages included it in their ``new_oid()``'s signature.
- Straightening this out required adding ``last=`` everywhere, or removing it
- everywhere. Since recursion isn't actually needed, and there was no other
- use for ``last=``, removing it everywhere was the obvious choice.
-
-Tests
------
-
-- (3.4a3) The various flavors of the ``check2ZODBThreads`` and
- ``check7ZODBThreads`` tests are much less likely to suffer sproadic
- failures now.
-
-- (3.4a2) The test ``checkOldStyleRoot`` failed in Zope3, because of an
- obscure dependence on the ``Persistence`` package (which Zope3 doesn't use).
-
-ZApplication
+``transact``
------------
-- (3.4a8) The file ``ZApplication.py`` was moved, from ZODB to Zope(2). ZODB
- and Zope3 don't use it, but Zope2 does.
-
-- (3.4a7) The ``__call__`` method didn't work if a non-None ``connection``
- string argument was passed. Thanks to Stefan Holek for noticing.
-
-
-What's new in ZODB3 3.4a1?
-==========================
-Release date: 01-Apr-2005
-
-transaction
------------
-
-- ``get_transaction()`` is officially deprecated now, and will be removed
- in ZODB 3.6. Use the ``transaction`` package instead. For example,
- instead of::
-
- import ZODB
- ...
- get_transaction().commit()
-
- do::
-
- import transaction
- ...
- transaction.commit()
-
-DB
---
-
-- There is no longer a hard limit on the number of connections that
- ``DB.open()`` will create. In other words, ``DB.open()`` never blocks
- anymore waiting for an earlier connection to close, and ``DB.open()``
- always returns a connection now (while it wasn't documented, it was
- possible for ``DB.open()`` to return ``None`` before).
-
- ``pool_size`` continues to default to 7, but its meaning has changed:
- if more than ``pool_size`` connections are obtained from ``DB.open()``
- and not closed, a warning is logged; if more than twice ``pool_size``, a
- critical problem is logged. ``pool_size`` should be set to the maximum
- number of connections from the ``DB`` instance you expect to have open
- simultaneously.
-
- In addition, if a connection obtained from ``DB.open()`` becomes
- unreachable without having been explicitly closed, when Python's garbage
- collection reclaims that connection it no longer counts against the
- ``pool_size`` thresholds for logging messages.
-
- The following optional arguments to ``DB.open()`` are deprecated:
- ``transaction``, ``waitflag``, ``force`` and ``temporary``. If one
- is specified, its value is ignored, and ``DeprecationWarning`` is
- raised. In ZODB 3.6, these optional arguments will be removed.
-
-- Lightweight support for "multi-databases" is implemented. These are
- collections of named DB objects and associated open Connections, such
- that the Connection for any DB in the collection can be obtained from
- a Connection from any other DB in the collection. See the new test
- file ZODB/tests/multidb.txt for a tutorial doctest. Thanks to Christian
- Theune for his work on this during the PyCon 2005 ZODB sprint.
-
-ZEO compatibility
------------------
-
-There are severe restrictions on using ZEO servers and clients at or after
-ZODB 3.3 with ZEO servers and clients from ZODB versions before 3.3. See the
-reworked ``Compatibility`` section in ``README.txt`` for details. If
-possible, it will be easiest to move clients and servers to 3.3+
-simultaneously. With care, it's possible to use a 3.3+ ZEO server with
-pre-3.3 ZEO clients, but not possible to use a pre-3.3 ZEO server with 3.3+
-ZEO clients.
-
-BTrees
-------
-
-- A new family of BTree types, in the ``IFBTree`` module, map
- signed integers (32 bits) to C floats (also 32 bits). The
- intended use is to help construct search indices, where, e.g.,
- integer word or document identifiers map to scores of some
- kind. This is easier than trying to work with scaled integer
- scores in an ``IIBTree``, and Zope3 has moved to ``IFBTrees``
- for these purposes in its search code.
-
-FileStorage
------------
-
-- Addded a record iteration protocol to FileStorage. You can use the
- record iterator to iterate over all current revisions of data
- pickles in the storage.
-
- In order to support calling via ZEO, we don't implement this as an
- actual iterator. An example of using the record iterator protocol
- is as follows::
-
- storage = FileStorage('anexisting.fs')
- next_oid = None
- while True:
- oid, tid, data, next_oid = storage.record_iternext(next_oid)
- # do something with oid, tid and data
- if next_oid is None:
- break
-
- The behavior of the iteration protocol is now to iterate over all
- current records in the database in ascending oid order, although
- this is not a promise to do so in the future.
-
-
-Tools
------
-
-New tool fsoids.py, for heavy debugging of FileStorages; shows all
-uses of specified oids in the entire database (e.g., suppose oid 0x345620
-is missing -- did it ever exist? if so, when? who referenced it? when
-was the last transaction that modified an object that referenced it?
-which objects did it reference? what kind of object was it?).
-ZODB/test/testfsoids.py is a tutorial doctest.
-
-
-fsIndex
--------
-
-Efficient, general implementations of ``minKey()`` and ``maxKey()`` methods
-were added. ``fsIndex`` is a special hybrid kind of BTree used to implement
-FileStorage indices. Thanks to Chris McDonough for code and tests.
-
-
-What's new in ZODB3 3.3.1?
-==========================
-Release date: DD-MMM-2005
-
-Tests
------
-
-The various flavors of the ``check2ZODBThreads`` and ``check7ZODBThreads``
-tests are much less likely to suffer sproadic failures now.
-
-
-What's new in ZODB3 3.3.1c1?
-============================
-Release date: 01-Apr-2005
-
-BTrees
-------
-
-Collector #1734: BTrees conflict resolution leads to index inconsistencies.
-
-Silent data loss could occur due to BTree conflict resolution when one
-transaction T1 added a new key to a BTree containing at least three buckets,
-and a concurrent transaction T2 deleted all keys in the bucket to which the
-new key was added. Conflict resolution then created a bucket containing the
-newly added key, but the bucket remained isolated, disconnected from the
-BTree. In other words, the committed BTree didn't contain the new key added by
-T1. Conflict resolution doesn't have enough information to repair this,
-so ``ConflictError`` is now raised in such cases.
-
-
-ZEO
----
-
-Repaired subtle race conditions in establishing ZEO connections, both client-
-and server-side. These account for intermittent cases where ZEO failed
-to make a connection (or reconnection), accompanied by a log message showing
-an error caught in ``asyncore`` and having a traceback ending with:
-
- ``UnpicklingError: invalid load key, 'Z'.``
-
-or:
-
- ``ZRPCError: bad handshake '(K\x00K\x00U\x0fgetAuthProtocol)t.'``
-
-or:
-
- ``error: (9, 'Bad file descriptor')``
-
-or an ``AttributeError``.
-
-These were exacerbated when running the test suite, because of an unintended
-busy loop in the test scaffolding, which could starve the thread trying to
-make a connection. The ZEO reconnection tests may run much faster now,
-depending on platform, and should suffer far fewer (if any) intermittent
-"timed out waiting for storage to connect" failures.
-
-ZEO protocol and compatibility
-------------------------------
-
-ZODB 3.3 introduced multiversion concurrency control (MVCC), which required
-changes to the ZEO protocol. The first 3.3 release should have increased
-the internal ZEO protocol version number (used by ZEO protocol negotiation
-when a client connects), but neglected to. This has been repaired.
-
-Compatibility between pre-3.3 and post-3.3 ZEO clients and servers remains
-very limited. See the newly updated ``Compatibility`` section in
-``README.txt`` for details.
-
-FileStorage
------------
-
-- The ``.store()`` and ``.restore()`` methods didn't update the storage's
- belief about the largest oid in use when passed an oid larger than the
- largest oid the storage already knew about. Because ``.restore()`` in
- particular is used by ``copyTransactionsFrom()``, and by the first stage
- of ZRS recovery, a large database could be created that believed the only
- oid in use was oid 0 (the special oid reserved for the root object). In
- rare cases, it could go on from there assigning duplicate oids to new
- objects, starting over from oid 1 again. This has been repaired. A
- new ``set_max_oid()`` method was added to the ``BaseStorage`` class so
- that derived storages can update the largest oid in use in a threadsafe
- way.
-
-- A FileStorage's index file tried to maintain the index's largest oid as a
- separate piece of data, incrementally updated over the storage's lifetime.
- This scheme was more complicated than necessary, so was also more brittle
- and slower than necessary. It indirectly participated in a rare but
- critical bug: when a FileStorage was created via
- ``copyTransactionsFrom()``, the "maximum oid" saved in the index file was
- always 0. Use that FileStorage, and it could then create "new" oids
- starting over at 0 again, despite that those oids were already in use by
- old objects in the database. Packing a FileStorage has no reason to
- try to update the maximum oid in the index file either, so this kind of
- damage could (and did) persist even across packing.
-
- The index file's maximum-oid data is ignored now, but is still written
- out so that ``.index`` files can be read by older versions of ZODB.
- Finding the true maximum oid is done now by exploiting that the main
- index is really a kind of BTree (long ago, this wasn't true), and finding
- the largest key in a BTree is inexpensive.
-
-- A FileStorage's index file could be updated on disk even if the storage
- was opened in read-only mode. That bug has been repaired.
-
-- An efficient ``maxKey()`` implementation was added to class ``fsIndex``.
-
-
-Pickle (in-memory Connection) Cache
------------------------------------
-
-You probably never saw this exception:
-
- ``ValueError: Can not re-register object under a different oid``
-
-It's been changed to say what it meant:
-
- ``ValueError: A different object already has the same oid``
-
-This happens if an attempt is made to add distinct objects to the cache
-that have the same oid (object identifier). ZODB should never do this,
-but it's possible for application code to force such an attempt.
-
-PersistentMapping and PersistentList
-------------------------------------
-
-Backward compatibility code has been added so that the sanest of the
-ZODB 3.2 dotted paths for ``PersistentMapping`` and ``PersistentList``
-resolve. These are still preferred:
-
-- ``from persistent.list import PersistentList``
-- ``from persistent.mapping import PersistentMapping``
-
-but these work again too:
-
-- ``from ZODB.PersistentList import PersistentList``
-- ``from ZODB.PersistentMapping import PersistentMapping``
-
-BTrees
-------
-
-The BTrees interface file neglected to document the optional
-``excludemin`` and ``excludemax`` arguments to the ``keys()``, ``values()``
-and ``items()`` methods. Appropriate changes were merged in from the
-ZODB4 BTrees interface file.
-
-Tools
------
-
-- ``mkzeoinst.py``'s default port number changed from to 9999 to 8100, to
- match the example in Zope's ``zope.conf``.
-
-fsIndex
--------
-
-An efficient ``maxKey()`` method was implemented for the ``fsIndex`` class.
-This makes it possible to determine the largest oid in a ``FileStorage``
-index efficiently, directly, and reliably, replacing a more delicate scheme
-that tried to keep track of this by saving an oid high water mark in the
-index file and incrementally updating it.
-
-
-What's new in ZODB3 3.3.1a1?
-============================
-Release date: 11-Jan-2005
-
-ZEO client cache
-----------------
-
-- Collector 1536: The ``cache-size`` configuration option for ZEO clients
- was being ignored. Worse, the client cache size was only one megabyte,
- much smaller than the advertised default of 20MB. Note that the default
- is carried over from a time when gigabyte disks were expensive and rare;
- 20MB is also too small on most modern machines.
-
-- Fixed a nasty bug in cache verification. A persistent ZEO cache uses a
- disk file, and, when active, has some in-memory data structures too to
- speed operation. Invalidations processed as part of startup cache
- verification were reflected in the in-memory data structures, but not
- correctly in the disk file. So if an object revision was invalidated as
- part of verification, the object wasn't loaded again before the connection
- was closed, and the object revision remained in the cache file until the
- connection was closed, then the next time the cache file was opened it
- could believe that the stale object revision in the file was actually
- current.
-
-- Fixed a bug wherein an object removed from the client cache didn't
- properly mark the file slice it occupied as being available for reuse.
-
-ZEO
----
-
-Collector 1503: excessive logging. It was possible for a ZEO client to
-log "waiting for cache verification to finish" messages at a very high
-rate, producing gigabytes of such messages in short order.
-``ClientStorage._wait_sync()`` was changed to log no more than one
-such message per 5 minutes.
-
-persistent
-----------
-
-Collector #1350: ZODB has a default one-thread-per-connection model, and
-two threads should never do operations on a single connection
-simultaneously. However, ZODB can't detect violations, and this happened
-in an early stage of Zope 2.8 development. The low-level ``ghostify()``
-and ``unghostify()`` routines in ``cPerisistence.c`` were changed to give
-some help in detecting this when it happens. In a debug build, both abort
-the process if thread interference is detected. This is extreme, but
-impossible to overlook. In a release build, ``unghostify()`` raises
-``SystemError`` if thread damage is detected; ``ghostify()`` ignores the
-problem in a release build (``ghostify()`` is supposed to be so simple that
-it "can't fail").
-
-ConflictError
--------------
-
-New in 3.3, a ``ConflictError`` exception may attempt to insert the path to
-the object's class in its message. However, a ZEO server may not have
-access to application class implementations, and then the attempt by the
-server to raise ``ConflictError`` could raise ``ImportError`` instead while
-trying to determine the object's class path. This was confusing. The code
-has been changed to obtain the class path from the object's pickle, without
-trying to import application modules or classes.
-
-FileStorage
------------
-
-Collector 1581: When an attempt to pack a corrupted ``Data.fs`` file was
-made, it was possible for the pack routine to die with a reference to an
-undefined global while it was trying to raise ``CorruptedError``. It
-raises ``CorruptedError``, as it always intended, in these cases now.
-
-Install
--------
-
-The C header file ``ring.h`` is now installed.
-
-Tools
------
-
-- ``BTrees.check.display()`` now displays the oids (if any) of the
- BTree's or TreeSet's constituent objects.
-
-
-What's new in ZODB3 3.3?
-========================
-Release date: 06-Oct-2004
-
-ZEO
----
-
-The encoding of RPC calls between server and client was being done
-with protocol 0 ("text mode") pickles, which could require sending
-four times as many bytes as necessary. Protocol 1 pickles are used
-now. Thanks to Andreas Jung for the diagnosis and cure.
-
-ZODB/component.xml
-------------------
-
-``cache-size`` parameters were changed from type ``integer`` to
-type ``byte-size``. This allows you to specify, for example,
-"``cache-size 20MB``" to get a 20 megabyte cache.
-
-transaction
------------
-
-The deprecation warning for ``Transaction.begin()`` was changed to
-point to the caller, instead of to ``Transaction.begin()`` itself.
-
-Connection
-----------
-
-Restored Connection's private ``_opened`` attribute. This was still
-referenced by ``DB.connectionDebugInfo()``, and Zope 2 calls the latter.
-
-FileStorage
------------
-
-Collector #1517: History tab for ZPT does not work. ``FileStorage.history()``
-was reading the user, description, and extension fields out of the object
-pickle, due to starting the read at a wrong location. Looked like
-cut-and-paste repetition of the same bug in ``FileStorage.FileIterator``
-noted in the news for 3.3c1.
-
-What's new in ZODB3 3.3 release candidate 1?
-============================================
-Release date: 14-Sep-2004
-
-Connection
-----------
-
-ZODB intends to raise ``ConnnectionStateError`` if an attempt is made to
-close a connection while modifications are pending (the connection is
-involved in a transaction that hasn't been ``abort()``'ed or
-``commit()``'ed). It was missing the case where the only pending
-modifications were made in subtransactions. This has been fixed. If an
-attempt to close a connection with pending subtransactions is made now::
-
- ConnnectionStateError: Cannot close a connection with a pending subtransaction
-
-is raised.
-
-transaction
------------
-
-- Transactions have new, backward-incompatible behavior in one respect:
- if a ``Transaction.commit()``, ``Transaction.commit(False)``, or
- ``Transaction.commit(True)`` raised an exception, prior behavior was that
- the transaction effectively aborted, and a new transaction began.
- A primary bad consequence was that, if in a sequence of subtransaction
- commits, one of the commits failed but the exception was suppressed,
- all changes up to and including the failing commit were lost, but
- later subtransaction commits in the sequence got no indication that
- something had gone wrong, nor did the final (top level) commit. This
- could easily lead to inconsistent data being committed, from the
- application's point of view.
-
- The new behavior is that a failing commit "sticks" until explicitly
- cleared. Now if an exception is raised by a ``commit()`` call (whether
- subtransaction or top level) on a Transaction object ``T``:
-
- - Pending changes are aborted, exactly as they were for a failing
- commit before.
-
- - But ``T`` remains the current transaction object (if ``tm`` is ``T``'s
- transaction manger, ``tm.get()`` continues to return ``T``).
-
- - All subsequent attempts to do ``T.commit()``, ``T.join()``, or
- ``T.register()`` raise the new ``TransactionFailedError`` exception.
- Note that if you try to modify a persistent object, that object's
- resource manager (usually a ``Connection`` object) will attempt to
- ``join()`` the failed transaction, and ``TransactionFailedError``
- will be raised right away.
-
- So after a transaction or subtransaction commit fails, that must be
- explicitly cleared now, either by invoking ``abort()`` on the transaction
- object, or by invoking ``begin()`` on its transaction manager.
-
-- Some explanations of new transaction features in the 3.3a3 news
- were incorrect, and this news file has been retroactively edited to
- repair that. See news for 3.3a3 below.
-
-- If ReadConflictError was raised by an attempt to load an object with a
- ``_p_independent()`` method that returned false, attempting to commit the
- transaction failed to (re)raise ReadConflictError for that object. Note
- that ZODB intends to prevent committing a transaction in which a
- ReadConflictError occurred; this was an obscure case it missed.
-
-- Growing pains: ZODB 3.2 had a bug wherein ``Transaction.begin()`` didn't
- abort the current transaction if the only pending changes were in a
- subtransaction. In ZODB 3.3, it's intended that a transaction manager be
- used to effect ``begin()`` (instead of invoking ``Transaction.begin()``),
- and calling ``begin()`` on a transaction manager didn't have this old
- bug. However, ``Transaction.begin()`` still exists in 3.3, and it had a
- worse bug: it never aborted the transaction (not even if changes were
- pending outside of subtransactions). ``Transaction.begin()`` has been
- changed to abort the transaction. ``Transaction.begin()`` is also
- deprecated. Don't use it. Use ``begin()`` on the relevant transaction
- manager instead. For example,
-
- >>> import transaction
- >>> txn = transaction.begin() # start a txn using the default TM
-
- if using the default ``ThreadTransactionManager`` (see news for 3.3a3
- below). In 3.3, it's intended that a single ``Transaction`` object is
- used for exactly one transaction. So, unlike as in 3.2, when somtimes
- ``Transaction`` objects were reused across transactions, but sometimes
- weren't, when you do ``Transaction.begin()`` in 3.3 a brand new
- transaction object is created. That's why this use is deprecated. Code
- of the form:
-
- >>> txn = transaction.get()
- >>> ...
- >>> txn.begin()
- >>> ...
- >>> txn.commit()
-
- can't work as intended in 3.3, because ``txn`` is no longer the current
- ``Transaction`` object the instant ``txn.begin()`` returns.
-
-BTrees
-------
-
-The BTrees __init__.py file is now just a comment. It had been trying
-to set up support for (long gone) "int sets", and to import an old
-version of Zope's Interface package, which doesn't even ship with ZODB.
-The latter in particular created problems, at least clashing with
-PythonCAD's Interface package.
-
-POSException
-------------
-
-Collector #1488 (TemporaryStorage -- going backward in time). This
-confusion was really due to that the detail on a ConflictError exception
-didn't make sense. It called the current revision "was", and the old
-revision "now". The detail is much more informative now. For example,
-if the exception said::
-
- ConflictError: database conflict error (oid 0xcb22,
- serial was 0x03441422948b4399, now 0x034414228c3728d5)
-
-before, it now says::
-
- ConflictError: database conflict error (oid 0xcb22,
- serial this txn started with 0x034414228c3728d5 2002-04-14 20:50:32.863000,
- serial currently committed 0x03441422948b4399 2002-04-14 20:50:34.815000)
-
-ConflictError
--------------
-
-The undocumented ``get_old_serial()`` and ``get_new_serial()`` methods
-were swapped (the first returned the new serial, and the second returned
-the old serial).
-
-Tools
------
-
-``FileStorage.FileIterator`` was confused about how to read a transaction's
-user and description fields, which caused several tools to display
-binary gibberish for these values.
-
-``ZODB.utils.oid_repr()`` changed to add a leading "0x", and to strip
-leading zeroes. This is used, e.g., in the detail of a ``POSKeyError``
-exception, to identify the missing oid. Before, the output was ambiguous.
-For example, oid 17 was displayed as 0000000000000011. As a Python
-integer, that's octal 9. Or was it meant to be decimal 11? Or was it
-meant to be hex? Now it displays as 0x11.
-
-fsrefs.py:
-
- When run with ``-v``, produced tracebacks for objects whose creation was
- merely undone. This was confusing. Tracebacks are now produced only
- if there's "a real" problem loading an oid.
-
- If the current revision of object O refers to an object P whose
- creation has been undone, this is now identified as a distinct case.
-
- Captured and ignored most attempts to stop it via Ctrl+C. Repaired.
-
- Now makes two passes, so that an accurate report can be given of all
- invalid references.
-
-``analyze.py`` produced spurious "len of unsized object" messages when
-finding a data record for an object uncreation or version abort. These
-no longer appear.
-
-``fsdump.py``'s ``get_pickle_metadata()`` function (which is used by several
-tools) was confused about what to do when the ZODB pickle started with
-a pickle ``GLOBAL`` opcode. It actually loaded the class then, which it
-intends never to do, leading to stray messages on stdout when the class
-wasn't available, and leading to a strange return value even when it was
-available (the repr of the type object was returned as "the module name",
-and an empty string was returned as "the class name"). This has been
-repaired.
-
-
-What's new in ZODB3 3.3 beta 2
-==============================
-Release date: 13-Aug-2004
-
-Transaction Managers
---------------------
-
-Zope3-dev Collector #139: Memory leak involving buckets and connections
-
-The transaction manager internals effectively made every Connection
-object immortal, except for those explicitly closed. Since typical
-practice is not to close connections explicitly (and closing a DB
-happens not to close the connections to it -- although that may
-change), this caused massive memory leaks when many connections were
-opened. The transaction manager internals were reworked to use weak
-references instead, so that connection memory (and other registered
-synch objects) now get cleaned up when nothing other than the
-transaction manager knows about them.
-
-Storages
---------
-
-Collector #1327: FileStorage init confused by time travel
-
-If the system clock "went backwards" a long time between the times a
-FileStorage was closed and reopened, new transaction ids could be
-smaller than transaction ids already in the storage, violating a
-key invariant. Now transaction ids are guaranteed to be increasing
-even when this happens. If time appears to have run backwards at all
-when a FileStorage is opened, a new message saying so is logged at
-warning level; if time appears to have run backwards at least 30
-minutes, the message is logged at critical level (and you should
-investigate to find and repair the true cause).
-
-Tools
------
-
-repozo.py: Thanks to a suggestion from Toby Dickenson, backups
-(whether incremental or full) are first written to a temp file now,
-which is fsync'ed at the end, and only after that succeeds is the
-file renamed to YYYY-MM-DD-HH-MM-SS.ext form. In case of a system
-crash during a repozo backup, this at least makes it much less
-likely that a backup file with incomplete or incorrect data will be
-left behind.
-
-fsrefs.py: Fleshed out the module docstring, and repaired a bug
-wherein spurious error msgs could be produced after reporting a
-problem with an unloadable object.
-
-Test suite
-----------
-
-Collector #1397: testTimeStamp fails on FreeBSD
-
- The BSD distributions are unique in that their mktime()
- implementation usually ignores the input tm_isdst value. Test
- checkFullTimeStamp() was sensitive to this platform quirk.
-
-Reworked the way some of the ZEO tests use threads, so that unittest is
-more likely to notice the real cause of a failure (which usually occurs in
-a thread), and less likely to latch on to spurious problems resulting from
-the real failure.
-
-
-What's new in ZODB3 3.3 beta 1
-==============================
-Release date: 07-Jun-2004
-
-3.3b1 is the first ZODB release built using the new zpkg tools:
-
- http://zope.org/Members/fdrake/zpkgtools/
-
-This appears to have worked very well. The structure of the tarball
-release differs from previous releases because of it, and the set of
-installed files includes some that were not installed in previous
-releases. That shouldn't create problems, so let us know if it does!
-We'll fine-tune this for the next release.
-
-BTrees
-------
-
-Fixed bug indexing BTreeItems objects with negative indexes. This
-caused reverse iteration to return each item twice. Thanks to Casey
-Duncan for the fix.
-
-ZODB
-----
-
-Methods removed from the database (ZODB.DB.DB) class: cacheStatistics(),
-cacheMeanAge(), cacheMeanDeac(), and cacheMeanDeal(). These were
-undocumented, untested, and unused. The first always returned an empty
-tuple, and the rest always returned None.
-
-When trying to do recovery to a time earlier than that of the most recent
-full backup, repozo.py failed to find the appropriate files, erroneously
-claiming "No files in repository before <specified time>". This has
-been repaired.
-
-Collector #1330: repozo.py -R can create corrupt .fs.
-When looking for the backup files needed to recreate a Data.fs file,
-repozo could (unintentionally) include its meta .dat files in the list,
-or random files of any kind created by the user in the backup directory.
-These would then get copied verbatim into the reconstructed file, filling
-parts with junk. Repaired by filtering the file list to include only
-files with the data extensions repozo.py creates (.fs, .fsz, .deltafs,
-and .deltafsz). Thanks to James Henderson for the diagnosis.
-
-fsrecover.py couldn't work, because it referenced attributes that no
-longer existed after the MVCC changes. Repaired that, and added new
-tests to ensure it continues working.
-
-Collector #1309: The reference counts reported by DB.cacheExtremeDetails()
-for ghosts were one too small. Thanks to Dieter Maurer for the diagnosis.
-
-Collector #1208: Infinite loop in cPickleCache.
-If a persistent object had a __del__ method (probably not a good idea
-regardless, but we don't prevent it) that referenced an attribute of
-self, the code to deactivate objects in the cache could get into an
-infinite loop: ghostifying the object could lead to calling its __del__
-method, the latter would load the object into cache again to
-satsify the attribute reference, the cache would again decide that
-the object should be ghostified, and so on. The infinite loop no longer
-occurs, but note that objects of this kind still aren't sensible (they're
-effectively immortal). Thanks to Toby Dickenson for suggesting a nice
-cure.
-
-
-What's new in ZODB3 3.3 alpha 3
-===============================
-Release date: 16-Apr-2004
-
-transaction
------------
-
-There is a new transaction package, which provides new interfaces for
-application code and for the interaction between transactions and
-resource managers.
-
-The top-level transaction package has functions ``commit()``, ``abort()``,
-``get()``, and ``begin()``. They should be used instead of the magic
-``get_transaction()`` builtin, which will be deprecated. For example:
-
- >>> get_transaction().commit()
-
-should now be written as
-
- >>> import transaction
- >>> transaction.commit()
-
-The new API provides explicit transaction manager objects. A transaction
-manager (TM) is responsible for associating resource managers with a
-"current" transaction. The default TM, implemented by class
-``ThreadedTransactionManager``, assigns each thread its own current
-transaction. This default TM is available as ``transaction.manager``. The
-``TransactionManager`` class assigns all threads to the same transaction,
-and is an explicit replacement for the ``Connection.setLocalTransaction()``
-method:
-
-A transaction manager instance can be passed as the transaction_manager
-argument to ``DB.open()``. If you do, the connection will use the specified
-transaction manager instead of the default TM. The current transaction is
-obtained by calling ``get()`` on a TM. For example:
-
- >>> tm = transaction.TransactionManager()
- >>> cn = db.open(transaction_manager=tm)
- [...]
- >>> tm.get().commit()
-
-The ``setLocalTransaction()`` and ``getTransaction()`` methods of
-Connection are deprecated. Use an explicit TM passed via
-``transaction_manager=`` to ``DB.open()`` instead. The
-``setLocalTransaction()`` method still works, but it returns a TM instead of
-a Transaction.
-
-A TM creates Transaction objects, which are used for exactly one
-transaction. Transaction objects still have ``commit()``, ``abort()``,
-``note()``, ``setUser()``, and ``setExtendedInfo()`` methods.
-
-Resource managers, e.g. Connection or RDB adapter, should use a
-Transaction's ``join()`` method instead of its ``register()`` method. An
-object that calls ``join()`` manages its own resources. An object that
-calls ``register()`` expects the TM to manage the objects.
-
-Data managers written against the ZODB 4 transaction API are now
-supported in ZODB 3.
-
-persistent
-----------
-
-A database can now contain persistent weak references. An object that
-is only reachable from persistent weak references will be removed by
-pack().
-
-The persistence API now distinguishes between deactivation and
-invalidation. This change is intended to support objects that can't
-be ghosts, like persistent classes. Deactivation occurs when a user
-calls _p_deactivate() or when the cache evicts objects because it is
-full. Invalidation occurs when a transaction updates the object. An
-object that can't be a ghost must load new state when it is
-invalidated, but can ignore deactivation.
-
-Persistent objects can implement a __getnewargs__() method that will
-be used to provide arguments that should be passed to __new__() when
-instances (including ghosts) are created. An object that implements
-__getnewargs__() must be loaded from storage even to create a ghost.
-
-There is new support for writing hooks like __getattr__ and
-__getattribute__. The new hooks require that user code call special
-persistence methods like _p_getattr() inside their hook. See the ZODB
-programming guide for details.
-
-The format of serialized persistent references has changed; that is,
-the on-disk format for references has changed. The old format is
-still supported, but earlier versions of ZODB will not be able to read
-the new format.
-
-ZODB
-----
-
-Closing a ZODB Connection while it is registered with a transaction,
-e.g. has pending modifications, will raise a ConnnectionStateError.
-Trying to load objects from or store objects to a closed connection
-will also raise a ConnnectionStateError.
-
-ZODB connections are synchronized on commit, even when they didn't
-modify objects. This feature assumes that the thread that opened the
-connection is also the thread that uses it. If not, this feature will
-cause problems. It can be disabled by passing synch=False to open().
-
-New broken object support.
-
-New add() method on Connection. User code should not assign the
-_p_jar attribute of a new persistent object directly; a deprecation
-warning is issued in this case.
-
-Added a get() method to Connection as a preferred synonym for
-__getitem__().
-
-Several methods and/or specific optional arguments of methods have
-been deprecated. The cache_deactivate_after argument used by DB() and
-Connection() is deprecated. The DB methods getCacheDeactivateAfter(),
-getVersionCacheDeactivateAfter(), setCacheDeactivateAfter(), and
-setVersionCacheDeactivateAfter() are also deprecated.
-
-The old-style undo() method was removed from the storage API, and
-transactionalUndo() was renamed to undo().
-
-The BDBStorages are no longer distributed with ZODB.
-
-Fixed a serious bug in the new pack implementation. If pack was
-called on the storage and passed a time earlier than a previous pack
-time, data could be lost. In other words, if there are any two pack
-calls, where the time argument passed to the second call was earlier
-than the first call, data loss could occur. The bug was fixed by
-causing the second call to raise a StorageError before performing any
-work.
-
-Fixed a rare bug in pack: if a pack started during a small window of
-time near the end of a concurrent transaction's commit, it was possible
-for the pack attempt to raise a spurious
-
- CorruptedError: ... transaction with checkpoint flag set
-
-exception. This did no damage to the database, or to the transaction
-in progress, but no pack was performed then.
-
-By popular demand, FileStorage.pack() no longer propagates a
-
- FileStorageError: The database has already been packed to a
- later time or no changes have been made since the last pack
-
-exception. Instead that message is logged (at INFO level), and
-the pack attempt simply returns then (no pack is performed).
-
-ZEO
----
-
-Fixed a bug that prevented the -m / --monitor argument from working.
-
-zdaemon
--------
-
-Added a -m / --mask option that controls the umask of the subprocess.
-
-zLOG
-----
-
-The zLOG backend has been removed. zLOG is now just a facade over the
-standard Python logging package. Environment variables like
-STUPID_LOG_FILE are no longer honored. To configure logging, you need
-to follow the directions in the logging package documentation. The
-process is currently more complicated than configured zLOG. See
-test.py for an example.
-
-ZConfig
--------
-
-This release of ZODB contains ZConfig 2.1.
-
-More documentation has been written.
-
-Make sure keys specified as attributes of the <default> element are
-converted by the appropriate key type, and are re-checked for derived
-sections.
-
-Refactored the ZConfig.components.logger schema components so that a
-schema can import just one of the "eventlog" or "logger" sections if
-desired. This can be helpful to avoid naming conflicts.
-
-Added a reopen() method to the logger factories.
-
-Always use an absolute pathname when opening a FileHandler.
-
-
-Miscellaneous
--------------
-
-The layout of the ZODB source release has changed. All the source
-code is contained in a src subdirectory. The primary motivation for
-this change was to avoid confusion caused by installing ZODB and then
-testing it interactively from the source directory; the interpreter
-would find the uncompiled ZODB package in the source directory and
-report an import error.
-
-A reference-counting bug was fixed, in the logic calling a modified
-persistent object's data manager's register() method. The primary symptom
-was rare assertion failures in Python's cyclic garbage collection.
-
-The Connection class's onCommitAction() method was removed.
-
-Some of the doc strings in ZODB are now written for processing by
-epydoc.
-
-Several new test suites were written using doctest instead of the
-standard unittest TestCase framework.
-
-MappingStorage now implements getTid().
-
-ThreadedAsync: Provide a way to shutdown the servers using an exit
-status.
-
-The mkzeoinstance script looks for a ZODB installation, not a Zope
-installation. The received wisdom is that running a ZEO server
-without access to the appserver code avoids many mysterious problems.
-
-
-What's new in ZODB3 3.3 alpha 2
-===============================
-Release date: 06-Jan-2004
-
-This release contains a major overhaul of the persistence machinery,
-including some user-visible changes. The Persistent base class is now
-a new-style class instead of an ExtensionClass. The change enables
-the use of features like properties with persistent object classes.
-The Persistent base class is now contained in the persistent package.
-
-The Persistence package is included for backwards compatibility. The
-Persistence package is used by Zope to provide special
-ExtensionClass-compatibility features like a non-C3 MRO and an __of__
-method. ExtensionClass is not included with this release of ZODB3.
-If you use the Persistence package, it will print a warning and import
-Persistent from persistent.
-
-In short, the new persistent package is recommended for non-Zope
-applications. The following dotted class names are now preferred over
-earlier names:
-
-- persistent.Persistent
-- persistent.list.PersistentList
-- persistent.mapping.PersistentMapping
-- persistent.TimeStamp
-
-The in-memory, per-connection object cache (pickle cache) was changed
-to participate in garbage collection. This should reduce the number
-of memory leaks, although we are still tracking a few problems.
-
-Multi-version concurrency control
----------------------------------
-
-ZODB now supports multi-version concurrency control (MVCC) for
-storages that support multiple revisions. FileStorage and
-BDBFullStorage both support MVCC. In short, MVCC means that read
-conflicts should almost never occur. When an object is modified in
-one transaction, other concurrent transactions read old revisions of
-the object to preserve consistency. In earlier versions of ZODB, any
-access of the modified object would raise a ReadConflictError.
-
-The ZODB internals changed significantly to accommodate MVCC. There
-are relatively few user visible changes, aside from the lack of read
-conflicts. It is possible to disable the MVCC feature using the mvcc
-keyword argument to the DB open() method, ex.: db.open(mvcc=False).
-
-ZEO
----
-
-Changed the ZEO server and control process to work with a single
-configuration file; this is now the default way to configure these
-processes. (It's still possible to use separate configuration files.)
-The ZEO configuration file can now include a "runner" section used by
-the control process and ignored by the ZEO server process itself. If
-present, the control process can use the same configuration file.
-
-Fixed a performance problem in the logging code for the ZEO protocol.
-The logging code could call repr() on arbitrarily long lists, even
-though it only logged the first 60 bytes; worse, it called repr() even
-if logging was currently disabled. Fixed to call repr() on individual
-elements until the limit is reached.
-
-Fixed a bug in zrpc (when using authentication) where the MAC header
-wasn't being read for large messages, generating errors while unpickling
-commands sent over the wire. Also fixed the zeopasswd.py script, added
-testcases and provided a more complete commandline interface.
-
-Fixed a misuse of the _map variable in zrpc Connectio objects, which
-are also asyncore.dispatcher objects. This allows ZEO to work with
-CVS Python (2.4). _map is used to indicate whether the dispatcher
-users the default socket_map or a custom socket_map. A recent change
-to asyncore caused it to use _map in its add_channel() and
-del_channel() methods, which presumes to be a bug fix (may get ported
-to 2.3). That causes our dubious use of _map to be a problem, because
-we also put the Connections in the global socket_map. The new
-asyncore won't remove it from the global socket map, because it has a
-custom _map.
-
-The prefix used for log messages from runzeo.py was changed from
-RUNSVR to RUNZEO.
-
-Miscellaneous
--------------
-
-ReadConflictError objects now have an ignore() method. Normally, a
-transaction that causes a read conflict can't be committed. If the
-exception is caught and its ignore() method called, the transaction
-can be committed. Application code may need this in advanced
-applications.
-
-
-What's new in ZODB3 3.3 alpha 1
-===============================
-Release date: 17-Jul-2003
-
-New features of Persistence
----------------------------
-
-The Persistent base class is a regular Python type implemented in C.
-It should be possible to create new-style classes that inherit from
-Persistent, and, thus, use all the new Python features introduced in
-Python 2.2 and 2.3.
-
-The __changed__() method on Persistent objects is no longer supported.
-
-New features in BTrees
-----------------------
-
-BTree, Bucket, TreeSet and Set objects are now iterable objects, playing
-nicely with the iteration protocol introduced in Python 2.2, and can
-be used in any context that accepts an iterable object. As for Python
-dicts, the iterator constructed for BTrees and Buckets iterates
-over the keys.
-
->>> from BTrees.OOBTree import OOBTree
->>> b = OOBTree({"one": 1, "two": 2, "three": 3, "four": 4})
->>> for key in b: # iterates over the keys
-... print key
-four
-one
-three
-two
->>> list(enumerate(b))
-[(0, 'four'), (1, 'one'), (2, 'three'), (3, 'two')]
->>> i = iter(b)
->>> i.next()
-'four'
->>> i.next()
-'one'
->>> i.next()
-'three'
->>> i.next()
-'two'
->>>
-
-As for Python dicts in 2.2, BTree and Bucket objects have new
-.iterkeys(), .iteritems(), and .itervalues() methods. TreeSet and Set
-objects have a new .iterkeys() method. Unlike as for Python dicts,
-these new methods accept optional min and max arguments to effect
-range searches. While Bucket.keys() produces a list, Bucket.iterkeys()
-produces an iterator, and similarly for Bucket values() versus
-itervalues(), Bucket items() versus iteritems(), and Set keys() versus
-iterkeys(). The iter{keys,values,items} methods of BTrees and the
-iterkeys() method of Treesets also produce iterators, while their
-keys() (etc) methods continue to produce BTreeItems objects (a form of
-"lazy" iterator that predates Python 2.2's iteration protocol).
-
->>> sum(b.itervalues())
-10
->>> zip(b.itervalues(), b.iterkeys())
-[(4, 'four'), (1, 'one'), (3, 'three'), (2, 'two')]
->>>
-
-BTree, Bucket, TreeSet and Set objects also implement the __contains__
-method new in Python 2.2, which means that testing for key membership
-can be done directly now via the "in" and "not in" operators:
-
->>> "won" in b
-False
->>> "won" not in b
-True
->>> "one" in b
-True
->>>
-
-All old and new range-search methods now accept keyword arguments,
-and new optional excludemin and excludemax keyword arguments. The
-new keyword arguments allow doing a range search that's exclusive
-at one or both ends (doesn't include min, and/or doesn't include
-max).
-
->>> list(b.keys())
-['four', 'one', 'three', 'two']
->>> list(b.keys(max='three'))
-['four', 'one', 'three']
->>> list(b.keys(max='three', excludemax=True))
-['four', 'one']
->>>
-
-Other improvements
-------------------
-
-The exceptions generated by write conflicts now contain the name of
-the conflicted object's class. This feature requires support for the
-storage. All the standard storages support it.
-
-What's new in ZODB3 3.2
-========================
-Release date: 08-Oct-2003
-
-Nothing has changed since release candidate 1.
-
-What's new in ZODB3 3.2 release candidate 1
-===========================================
-Release date: 01-Oct-2003
-
-Added a summary to the Doc directory. There are several new documents
-in the 3.2 release, including "Using zdctl and zdrun to manage server
-processes" and "Running a ZEO Server HOWTO."
-
-Fixed ZEO's protocol negotiation mechanism so that a client ZODB 3.1
-can talk to a ZODB 3.2 server.
-
-Fixed a memory leak in the ZEO server. The server was leaking a few
-KB of memory per connection.
-
-Fixed a memory leak in the ZODB object cache (cPickleCache). The
-cache did not release two references to its Connection, causing a
-large cycle of objects to leak when a database was closed.
-
-Fixed a bug in the ZEO code that caused it to leak socket objects on
-Windows. Specifically, fix the trigger mechanism so that both sockets
-created for a trigger are closed.
-
-Fixed a bug in the ZEO storage server that caused it to leave temp
-files behind. The CommitLog class contains a temp file, but it was
-not closing the file.
-
-Changed the order of setuid() and setgid() calls in zdrun, so that
-setgid() is called first.
-
-Added a timeout to the ZEO test suite that prevents hangs. The test
-suite creates ZEO servers with randomly assigned ports. If the port
-happens to be in use, the test suite would hang because the ZEO client
-would never stop trying to connect. The fix will cause the test to
-fail after a minute, but should prevent the test runner from hanging.
-
-The logging package was updated to include the latest version of the
-logging package from Python CVS. Note that this package is only
-installed for Python 2.2. In later versions of Python, it is
-available in the Python standard library.
-
-The ZEO1 directory was removed from the source distribution. ZEO1 is
-not supported, and we never intended to include it in the release.
-
-What's new in ZODB3 3.2 beta 3
-==============================
-Release date: 23-Sep-2003
-
-Note: The changes listed for this release include changes also made in
-ZODB 3.1.x releases and ported to the 3.2 release.
-
-This version of ZODB 3.2 is not compatible with Python 2.1. Early
-versions were explicitly designed to be compatible with Zope 2.6.
-That plan has been dropped, because Zope 2.7 is already in beta
-release.
-
-Several of the classes in ZEO and ZODB now inherit from object, making
-them new-style classes. The primary motivation for the change was to
-make it easier to debug memory leaks. We don't expect any behavior to
-change as a result.
-
-A new feature to allow removal of connection pools for versions was
-ported from Zope 2.6. This feature is needed by Zope to avoid denial
-of service attacks that allow a client to create an arbitrary number
-of version pools.
-
-Fixed several critical ZEO bugs.
-
-- If several client transactions were blocked waiting for the storage
- and one of the blocked clients disconnected, the server would
- attempt to restart one of the other waiting clients. Since the
- disconnected client did not have the storage lock, this could lead
- to deadlock. It could also cause the assertion "self._client is
- None" to fail.
-
-- If a storage server fails or times out between the vote and the
- finish, the ZEO cache could get populated with objects that didn't
- make it to the storage server.
-
-- If a client loses its connection to the server near the end of a
- transaction, it is now guaranteed to get a ClientDisconnected error
- even if it reconnects before the transaction finishes. This is
- necessary because the server will always abort the transaction.
- In some cases, the client would never see an error for the aborted
- transaction.
-
-- In tpc_finish(), reordered the calls so that the server's tpc_finish()
- is called (and must succeed) before we update the ZEO client cache.
-
-- The storage name is now prepended to the sort key, to ensure a
- unique global sort order if storages are named uniquely. This
- can prevent deadlock in some unusual cases.
-
-Fixed several serious flaws in the implementation of the ZEO
-authentication protocol.
-
-- The smac layer would accept a message without a MAC even after the
- session key was established.
-
-- The client never initialized its session key, so it never checked
- incoming messages or created MACs for outgoing messags.
-
-- The smac layer used a single HMAC instance for sending and receiving
- messages. This approach could only work if client and server were
- guaranteed to process all messages in the same total order, which
- could only happen in simple scenarios like unit tests.
-
-Fixed a bug in ExtensionClass when comparing ExtensionClass instances.
-The code could raise RuntimeWarning under Python 2.3, and produce
-incorrect results on 64-bit platforms.
-
-Fixed bug in BDBStorage that could lead to DBRunRecoveryErrors when a
-transaction was aborted after performing operations like commit
-version or undo that create new references to existing pickles.
-
-Fixed a bug in Connection.py that caused it to fail with an
-AttributeError if close() was called after the database was closed.
-
-The test suite leaves fewer log files behind, although it still leaves
-a lot of junk. The test.py script puts each tests temp files in a
-separate directory, so it is easier to see which tests are causing
-problems. Unfortunately, it is still to tedious to figure out why the
-identified tests are leaving files behind.
-
-This release contains the latest and greatest version of the
-BDBStorage. This storage has still not seen testing in a production
-environment, but it represents the current best design and most recent
-code culled from various branches where development has occurred.
-
-The Tools directory contains a number of small improvements, a few new
-tools, and README.txt that catalogs the tools. Many of the tools are
-installed by setup.py; those scripts will now have a #! line set
-automatically on Unix.
-
-Fixed bugs in Tools/repozo.py, including a timing-dependent one that
-could cause the following invocation of repozo to do a full backup when
-an incremental backup would have sufficed.
-
-A pair of new scripts from Jim Fulton can be used to synthesize
-workloads and measure ZEO performance: see zodbload.py and
-zeoserverlog.py in the Tools directory. Note that these require
-Zope.
-
-Tools/checkbtrees.py was strengthened in two ways:
-
-- In addition to running the _check() method on each BTree B found,
- BTrees.check.check(B) is also run. The check() function was written
- after checkbtrees.py, and identifies kinds of damage B._check()
- cannot find.
-
-- Cycles in the object graph no longer lead to unbounded output.
- Note that preventing this requires remembering the oid of each
- persistent object found, which increases the memory needed by the
- script.
-
-What's new in ZODB3 3.2 beta 2
-==============================
-Release date: 16-Jun-2003
-
-Fixed critical race conditions in ZEO's cache consistency code that
-could cause invalidations to be lost or stale data to be written to
-the cache. These bugs can lead to data loss or data corruption.
-These bugs are relatively unlikely to be provoked in sites with few
-conflicts, but the possibility of failure existed any time an object
-was loaded and stored concurrently.
-
-Fixed a bug in conflict resolution that failed to ghostify an object
-if it was involved in a conflict. (This code may be redundant, but it
-has been fixed regardless.)
-
-The ZEO server was fixed so that it does not perform any I/O until all
-of a transactions' invalidations are queued. If it performs I/O in the
-middle of sending invalidations, it would be possible to overlap a
-load from a client with the invalidation being sent to it.
-
-The ZEO cache now handles invalidations atomically. This is the same
-sort of bug that is described in the 3.1.2b1 section below, but it
-affects the ZEO cache.
-
-Fixed several serious bugs in fsrecover that caused it to fail
-catastrophically in certain cases because it thought it had found a
-checkpoint (status "c") record when it was in the middle of the file.
-
-Two new features snuck into this beta release.
-
-The ZODB.transact module provides a helper function that converts a
-regular function or method into a transactional one.
-
-The ZEO client cache now supports Adaptable Persistence (APE). The
-cache used to expect that all OIDs were eight bytes long.
-
-What's new in ZODB3 3.2 beta 1
-==============================
-Release date: 30-May-2003
-
-ZODB
-----
-
-Invalidations are now processed atomically. Each transaction will see
-all the changes caused by an earlier transaction or none of them.
-Before this patch, it was possible for a transaction to see invalid
-data because it saw only a subset of the invalidations. This is the
-most likely cause of reported BTrees corruption, where keys were
-stored in the wrong bucket. When a BTree bucket splits, the bucket
-and the bucket's parent are both modified. If a transaction sees the
-invalidation for the bucket but not the parent, the BTree in memory
-will be internally inconsistent and keys can be put in the wrong
-bucket. The atomic invalidation fix prevents this problem.
-
-A number of minor reference count fixes in the object cache were
-fixed. That's the cPickleCache.c file.
-
-It was possible for a transaction that failed in tpc_finish() to lose
-the traceback that caused the failure. The transaction code was fixed
-to report the original error as well as any errors that occur while
-trying to recover from the original error.
-
-The "other" argument to copyTransactionsFrom() only needs to have an
-.iterator() method. For convenience, change FileStorage's and
-BDBFullStorage's iterator to have this method, which just returns
-self.
-
-Mount points are now visible from mounted objects.
-
-Fixed memory leak involving database connections and caches. When a
-connection or database was closed, the cache and database leaked,
-because of a circular reference involving the cache. Fixed the cache
-to explicitly clear out its contents when its connection is closed.
-
-The ZODB cache has fewer methods. It used to expose methods that
-could mutate the dictionary, which allowed users to violate internal
-invariants.
-
-ZConfig
--------
-
-It is now possible to configure ZODB databases and storages and ZEO
-servers using ZConfig.
-
-ZEO & zdaemon
--------------
-
-ZEO now supports authenticated client connections. The default
-authentication protocol uses a hash-based challenge-response protocol
-to prove identity and establish a session key for message
-authentication. The architecture is pluggable to allow third-parties
-to developer better authentication protocols.
-
-There is a new HOWTO for running a ZEO server. The draft in this
-release is incomplete, but provides more guidance than previous
-releases. See the file Doc/ZEO/howto.txt.
-
-
-The ZEO storage server's transaction timeout feature was refactored
-and made slightly more rebust.
-
-A new ZEO utility script, ZEO/mkzeoinst.py, was added. This creates a
-standard directory structure and writes a configuration file with
-mostly default values, and a bootstrap script that can be used to
-manage and monitor the server using zdctl.py (see below).
-
-Much work was done to improve zdaemon's zdctl.py and zdrun.py scripts.
-(In the alpha 1 release, zdrun.py was called zdaemon.py, but
-installing it in <prefix>/bin caused much breakage due to the name
-conflict with the zdaemon package.) Together with the new
-mkzeoinst.py script, this makes controlling a ZEO server a breeze.
-
-A ZEO client will not read from its cache during cache verification.
-This fix was necessary to prevent the client from reading inconsistent
-data.
-
-The isReadOnly() method of a ZEO client was fixed to return the false
-when the client is connected to a read-only fallback server.
-
-The sync() method of ClientStorage and the pending() method of a zrpc
-connection now do both input and output.
-
-The short_repr() function used to generate log messages was fixed so
-that it does not blow up creating a repr of very long tuples.
-
-Storages
---------
-
-FileStorage has a new pack() implementation that fixes several
-reported problems that could lead to data loss.
-
-Two small bugs were fixed in DemoStorage. undoLog() did not handle
-its arguments correctly and pack() could accidentally delete objects
-created in versions.
-
-Fixed trivial bug in fsrecover that prevented it from working at all.
-
-FileStorage will use fsync() on Windows starting with Python 2.2.3.
-
-FileStorage's commit version was fixed. It used to stop after the
-first object, leaving all the other objects in the version.
-
-BTrees
-------
-
-Trying to store an object of a non-integer type into an IIBTree
-or OIBTree could leave the bucket in a variety of insane states. For
-example, trying
-
- b[obj] = "I'm a string, not an integer"
-
-where b is an OIBTree. This manifested as a refcount leak in the test
-suite, but could have been much worse (most likely in real life is that
-a seemingly arbitrary existing key would "go missing").
-
-When deleting the first child of a BTree node with more than one
-child, a reference to the second child leaked. This could cause
-the entire bucket chain to leak (not be collected as garbage
-despite not being referenced anymore).
-
-Other minor BTree leak scenarios were also fixed.
-
-Tools
------
-
-New tool zeoqueue.py for parsing ZEO log files, looking for blocked
-transactions.
-
-New tool repozo.py (originally by Anthony Baxter) for performing
-incremental backups of Data.fs files.
-
-The fsrecover.py script now does a better job of recovering from
-errors the occur in the middle of a transaction record. Fixed several
-bugs that caused partial or total failures in earlier versions.
-
-
-What's new in ZODB3 3.2 alpha 1
-===============================
-Release date: 17-Jan-2003
-
-Most of the changes in this release are performance and stability
-improvements to ZEO. A major packaging change is that there won't be
-a separate ZEO release. The new ZConfig is a noteworthy addtion (see
-below).
-
-ZODB
-----
-
-An experimental new transaction API was added. The Connection class
-has a new method, setLocalTransaction(). ZODB applications can call
-this method to bind transactions to connections rather than threads.
-This is especially useful for GUI applications, which often have only
-one thread but multiple independent activities within that thread
-(generally one per window). Thanks to Christian Reis for championing
-this feature.
-
-Applications that take advantage of this feature should not use the
-get_transaction() function. Until now, ZODB itself sometimes assumed
-get_transaction() was the only way to get the transaction. Minor
-corrections have been added. The ZODB test suite, on the other hand,
-can continue to use get_transaction(), since it is free to assume that
-transactions are bound to threads.
-
-ZEO
----
-
-There is a new recommended script for starting a storage server. We
-recommend using ZEO/runzeo.py instead of ZEO/start.py. The start.py
-script is still available in this release, but it will no longer be
-maintained and will eventually be removed.
-
-There is a new zdaemon implementation. This version is a separate
-script that runs an arbitrary daemon. To run the ZEO server as a
-daemon, you would run "zdrun.py runzeo.py". There is also a simple
-shell, zdctl.py, that can be used to manage a daemon. Try
-"zdctl.py -p runzeo.py".
-
-There is a new version of the ZEO protocol in this release and a first
-stab at protocol negotiation. (It's a first stab because the protocol
-checking supporting in ZODB 3.1 was too primitive to support anything
-better.) A ZODB 3.2 ZEO client can talk to an old server, but a ZODB
-3.2 server can't talk to an old client. It's safe to upgrade all the
-clients first and upgrade the server last. The ZEO client cache
-format changed, so you'll need to delete persistent caches before
-restarting clients.
-
-The ZEO cache verification protocol was revised to require many fewer
-messages in cases where a client or server restarts quickly.
-
-The performance of full cache verification has improved dramatically.
-Measurements from Jim were somewhere in 2x-5x. The
-implementation was fixed to use the very-fast getSerial() method on
-the storage instead of the comparatively slow load().
-
-The ZEO server has an optional timeout feature that will abort a
-connection that does not commit within a certain amount of time. The
-timeout works by closing the socket the client is using, causing both
-client and server to abort the transaction and continue. This is a
-drastic step, but can be useful to prevent a hung client or other bug
-from blocking a server indefinitely.
-
-A bug was fixed in the ZEO protocol that allowed clients to read stale
-cache data while cache verification was being performed. The fixed
-version prevents the client from using the storage until after
-verification completes.
-
-The ZEO server has an experimental monitoring interface that reports
-usage statistics for the storage server including number of connected
-clients and number of transactions active and committed. It can be
-enabled by passing the -m flag to runsvr.py.
-
-The ZEO ClientStorage no longer supports the environment variables
-CLIENT_HOME, INSTANCE_HOME, or ZEO_CLIENT.
-
-The ZEO1 package is still included with this release, but there is no
-longer an option to install it.
-
-BTrees
-------
-
-The BTrees package now has a check module that inspects a BTree to
-check internal invariants. Bugs in older versions of the code code
-leave a BTree in an inconsistent state. Calling BTrees.check.check()
-on a BTree object should verify its consistency. (See the NEWS
-section for 3.1 beta 1 below to for the old BTrees bugs.)
-
-Fixed a rare conflict resolution problem in the BTrees that could
-cause an segfault when the conflict resolution resulted in any
-empty bucket.
-
-Installation
-------------
-
-The distutils setup now installs several Python scripts. The
-runzeo.py and zdrun.py scripts mentioned above and several fsXXX.py
-scripts from the Tools directory.
-
-The test.py script does not run all the ZEO tests by default, because
-the ZEO tests take a long time to run. Use --all to run all the
-tests. Otherwise a subset of the tests, mostly using MappingStorage,
-are run.
-
-Storages
---------
-
-There are two new storages based on Sleepycat's BerkeleyDB in the
-BDBStorage package. Barry will have to write more here, because I
-don't know how different they are from the old bsddb3Storage
-storages. See Doc/BDBStorage.txt for more information.
-
-It now takes less time to open an existing FileStorage. The
-FileStorage uses a BTree-based index that is faster to pickle and
-unpickle. It also saves the index periodically so that subsequent
-opens will go fast even if the storage was not closed cleanly.
-
-Misc
-----
-
-The new ZConfig package, which will be used by Zope and ZODB, is
-included. ZConfig provides a configuration syntax, similar to
-Apache's syntax. The package can be used to configure the ZEO server
-and ZODB databases. See the module ZODB.config for functions to open
-the database from configuration. See ZConfig/doc for more info.
-
-The zLOG package now uses the logging package by Vinay Sajip, which
-will be included in Python 2.3.
-
-The Sync extension was removed from ExtensionClass, because it was not
-used by ZODB.
-
-What's new in ZODB3 3.1.4?
-==========================
-Release date: 11-Sep-2003
-
-A new feature to allow removal of connection pools for versions was
-ported from Zope 2.6. This feature is needed by Zope to avoid denial
-of service attacks that allow a client to create an arbitrary number
-of version pools.
-
-A pair of new scripts from Jim Fulton can be used to synthesize
-workloads and measure ZEO performance: see zodbload.py and
-zeoserverlog.py in the Tools directory. Note that these require
-Zope.
-
-Tools/checkbtrees.py was strengthened in two ways:
-
-- In addition to running the _check() method on each BTree B found,
- BTrees.check.check(B) is also run. The check() function was written
- after checkbtrees.py, and identifies kinds of damage B._check()
- cannot find.
-
-- Cycles in the object graph no longer lead to unbounded output.
- Note that preventing this requires remembering the oid of each
- persistent object found, which increases the memory needed by the
- script.
-
-What's new in ZODB3 3.1.3?
-==========================
-Release date: 18-Aug-2003
-
-Fixed several critical ZEO bugs.
-
-- If a storage server fails or times out between the vote and the
- finish, the ZEO cache could get populated with objects that didn't
- make it to the storage server.
-
-- If a client loses its connection to the server near the end of a
- transaction, it is now guaranteed to get a ClientDisconnected error
- even if it reconnects before the transaction finishes. This is
- necessary because the server will always abort the transaction.
- In some cases, the client would never see an error for the aborted
- transaction.
-
-- In tpc_finish(), reordered the calls so that the server's tpc_finish()
- is called (and must succeed) before we update the ZEO client cache.
-
-- The storage name is now prepended to the sort key, to ensure a
- unique global sort order if storages are named uniquely. This
- can prevent deadlock in some unusual cases.
-
-A variety of fixes and improvements to Berkeley storage (aka BDBStorage)
-were back-ported from ZODB 4. This release now contains the most
-current version of the Berkeley storage code. Many tests have been
-back-ported, but not all.
-
-Modified the Windows tests to wait longer at the end of ZEO tests for
-the server to shut down. Before Python 2.3, there is no waitpid() on
-Windows, and, thus, no way to know if the server has shut down. The
-change makes the Windows ZEO tests much less likely to fail or hang,
-at the cost of increasing the time needed to run the tests.
-
-Fixed a bug in ExtensionClass when comparing ExtensionClass instances.
-The code could raise RuntimeWarning under Python 2.3, and produce
-incorrect results on 64-bit platforms.
-
-Fixed bugs in Tools/repozo.py, including a timing-dependent one that
-could cause the following invocation of repozo to do a full backup when
-an incremental backup would have sufficed.
-
-Added Tools/README.txt that explains what each of the scripts in the
-Tools directory does.
-
-There were many small changes and improvements to the test suite.
-
-What's new in ZODB3 3.1.2 final?
-================================
-
-Fixed bug in FileStorage pack that caused it to fail if it encountered
-an old undo record (status "u").
-
-Fixed several bugs in FileStorage pack that could cause OverflowErrors
-for storages > 2 GB.
-
-Fixed memory leak in TimeStamp.laterThan() that only occurred when it
-had to create a new TimeStamp.
-
-Fixed two BTree bugs that were fixed on the head a while ago:
-
- - bug in fsBTree that would cause byValue searches to end early.
- (fsBTrees are never used this way, but it was still a bug.)
-
- - bug that lead to segfault if BTree was mutated via deletion
- while it was being iterated over.
-
-What's new in ZODB3 3.1.2 beta 2?
-=================================
-
-Fixed critical race conditions in ZEO's cache consistency code that
-could cause invalidations to be lost or stale data to be written to
-the cache. These bugs can lead to data loss or data corruption.
-These bugs are relatively unlikely to be provoked in sites with few
-conflicts, but the possibility of failure existed any time an object
-was loaded and stored concurrently.
-
-Fixed a bug in conflict resolution that failed to ghostify an object
-if it was involved in a conflict. (This code may be redundant, but it
-has been fixed regardless.)
-
-The ZEO server was fixed so that it does not perform any I/O until all
-of a transactions' invalidations are queued. If it performs I/O in the
-middle of sending invalidations, it would be possible to overlap a
-load from a client with the invalidation being sent to it.
-
-The ZEO cache now handles invalidations atomically. This is the same
-sort of bug that is described in the 3.1.2b1 section below, but it
-affects the ZEO cache.
-
-Fixed several serious bugs in fsrecover that caused it to fail
-catastrophically in certain cases because it thought it had found a
-checkpoint (status "c") record when it was in the middle of the file.
-
-What's new in ZODB3 3.1.2 beta 1?
-=================================
-
-ZODB
-----
-
-Invalidations are now processed atomically. Each transaction will see
-all the changes caused by an earlier transaction or none of them.
-Before this patch, it was possible for a transaction to see invalid
-data because it saw only a subset of the invalidations. This is the
-most likely cause of reported BTrees corruption, where keys were
-stored in the wrong bucket. When a BTree bucket splits, the bucket
-and the bucket's parent are both modified. If a transaction sees the
-invalidation for the bucket but not the parent, the BTree in memory
-will be internally inconsistent and keys can be put in the wrong
-bucket. The atomic invalidation fix prevents this problem.
-
-A number of minor reference count fixes in the object cache were
-fixed. That's the cPickleCache.c file.
-
-It was possible for a transaction that failed in tpc_finish() to lose
-the traceback that caused the failure. The transaction code was fixed
-to report the original error as well as any errors that occur while
-trying to recover from the original error.
-
-ZEO
----
-
-A ZEO client will not read from its cache during cache verification.
-This fix was necessary to prevent the client from reading inconsistent
-data.
-
-The isReadOnly() method of a ZEO client was fixed to return the false
-when the client is connected to a read-only fallback server.
-
-The sync() method of ClientStorage and the pending() method of a zrpc
-connection now do both input and output.
-
-The short_repr() function used to generate log messages was fixed so
-that it does not blow up creating a repr of very long tuples.
-
-Storages
---------
-
-FileStorage has a new pack() implementation that fixes several
-reported problems that could lead to data loss.
-
-Two small bugs were fixed in DemoStorage. undoLog() did not handle
-its arguments correctly and pack() could accidentally delete objects
-created in versions.
-
-Fixed trivial bug in fsrecover that prevented it from working at all.
-
-FileStorage will use fsync() on Windows starting with Python 2.2.3.
-
-FileStorage's commit version was fixed. It used to stop after the
-first object, leaving all the other objects in the version.
-
-BTrees
-------
-
-Trying to store an object of a non-integer type into an IIBTree
-or OIBTree could leave the bucket in a variety of insane states. For
-example, trying
-
- b[obj] = "I'm a string, not an integer"
-
-where b is an OIBTree. This manifested as a refcount leak in the test
-suite, but could have been much worse (most likely in real life is that
-a seemingly arbitrary existing key would "go missing").
-
-When deleting the first child of a BTree node with more than one
-child, a reference to the second child leaked. This could cause
-the entire bucket chain to leak (not be collected as garbage
-despite not being referenced anymore).
-
-Other minor BTree leak scenarios were also fixed.
-
-Other
------
-
-Comparing a Missing.Value object to a C type that provide its own
-comparison operation could lead to a segfault when the Missing.Value
-was on the right-hand side of the comparison operator. The Missing
-class was fixed so that its coercion and comparison operations are
-safe.
-
-Tools
------
-
-Four tools are now installed by setup.py: fsdump.py, fstest.py,
-repozo.py, and zeopack.py.
-
-What's new in ZODB3 3.1.1 final?
-================================
-Release date: 11-Feb-2003
-
-Tools
------
-
-Updated repozo.py tool
-
-What's new in ZODB3 3.1.1 beta 2?
-=================================
-Release date: 03-Feb-2003
-
-The Transaction "hosed" feature is disabled in this release. If a
-transaction fails during the tpc_finish() it is not possible, in
-general, to know whether the storage is in a consistent state. For
-example, a ZEO server may commit the data and then fail before sending
-confirmation of the commit to the client. If multiple storages are
-involved in a transaction, the problem is exacerbated: One storage may
-commit the data while another fails to commit. In previous versions
-of ZODB, the database would set a global "hosed" flag that prevented
-any other transaction from committing until an administrator could
-check the status of the various failed storages and ensure that the
-database is in a consistent state. This approach favors data
-consistency over availability. The new approach is to log a panic but
-continue. In practice, availability seems to be more important than
-consistency. The failure mode is exceedingly rare in either case.
-
-The BTrees-based fsIndex for FileStorage is enabled. This version of
-the index is faster to load and store via pickle and uses less memory
-to store keys. We had intended to enable this feature in an earlier
-release, but failed to actually do it; thus, it's getting enabled as a
-bug fix now.
-
-Two rare bugs were fixed in BTrees conflict resolution. The most
-probable symptom of the bug would have been a segfault. The bugs
-were found via synthetic stress tests rather than bug reports.
-
-A value-based consistency checker for BTrees was added. See the
-module BTrees.check for the checker and other utilities for working
-with BTrees.
-
-A new script called repozo.py was added. This script, originally
-written by Anthony Baxter, provides an incremental backup scheme for
-FileStorage based storages.
-
-zeopack.py has been fixed to use a read-only connection.
-
-Various small autopack-related race conditions have been fixed in the
-Berkeley storage implementations. There have been some table changes
-to the Berkeley storages so any storage you created in 3.1.1b1 may not
-work. Part of these changes was to add a storage version number to
-the schema so these types of incompatible changes can be avoided in
-the future.
-
-Removed the chance of bogus warnings in the FileStorage iterator.
-
-ZEO
----
-
-The ZEO version number was bumped to 2.0.2 on account of the following
-minor feature additions.
-
-The performance of full cache verification has improved dramatically.
-Measurements from Jim were somewhere in 2x-5x. The
-implementation was fixed to use the very-fast getSerial() method on
-the storage instead of the comparatively slow load().
-
-The ZEO server has an optional timeout feature that will abort a
-connection that does not commit within a certain amount of time. The
-timeout works by closing the socket the client is using, causing both
-client and server to abort the transaction and continue. This is a
-drastic step, but can be useful to prevent a hung client or other bug
-from blocking a server indefinitely.
-
-If a client was disconnected during a transaction, the tpc_abort()
-call did not properly reset the internal state about the transaction.
-The bug caused the next transaction to fail in its tpc_finish().
-Also, any ClientDisconnected exceptions raised during tpc_abort() are
-ignored.
-
-ZEO logging has been improved by adding more logging for important
-events, and changing the logging level for existing messages to a more
-appropriate level (usually lower).
-
-What's new in ZODB3 3.1.1 beta 1?
-=================================
-Release date: 10-Dev-2002
-
-It was possible for earlier versions of ZODB to deadlock when using
-multiple storages. If multiple transactions committed concurrently
-and both transactions involved two or more shared storages, deadlock
-was possible. This problem has been fixed by introducing a sortKey()
-method to the transaction and storage APIs that is used to define an
-ordering on transaction participants. This solution will prevent
-deadlocks provided that all transaction participants that use locks
-define a valid sortKey() method. A warning is raised if a participant
-does not define sortKey(). For backwards compatibility, BaseStorage
-provides a sortKey() that uses __name__.
-
-Added code to ThreadedAsync/LoopCallback.py to work around a bug in
-asyncore.py: a handled signal can cause unwanted reads to happen.
-
-A bug in FileStorage related to object uncreation was fixed. If an
-a transaction that created an object was undone, FileStorage could
-write a bogus data record header that could lead to strange errors if
-the object was loaded. An attempt to load an uncreated object now
-raises KeyError, as expected.
-
-The restore() implementation in FileStorage wrote incorrect
-backpointers for a few corner cases involving versions and undo. It
-also failed if the backpointer pointed to a record that was before the
-pack time. These specific bugs have been fixed and new test cases
-were added to cover them.
-
-A bug was fixed in conflict resolution that raised a NameError when a
-class involved in a conflict could not be loaded. The bug did not
-affect correctness, but prevent ZODB from caching the fact that the
-class was unloadable. A related bug prevented spurious
-AttributeErrors when a class could not be loaded. It was also fixed.
-
-The script Tools/zeopack.py was fixed to work with ZEO 2. It was
-untested and had two silly bugs.
-
-Some C extensions included standard header files before including
-Python.h, which is not allowed. They now include Python.h first,
-which eliminates compiler warnings in certain configurations.
-
-The BerkeleyDB based storages have been merged from the trunk,
-providing a much more robust version of the storages. They are not
-backwards compatible with the old storages, but the decision was made
-to update them in this micro release because the old storages did not
-work for all practical purposes. For details, see Doc/BDBStorage.txt.
-
-What's new in ZODB3 3.1 final?
-===============================
-Release date: 28-Oct-2002
-
-If an error occurs during conflict resolution, the store will silently
-catch the error, log it, and continue as if the conflict was
-unresolvable. ZODB used to behave this way, and the change to catch
-only ConflictError was causing problems in deployed systems. There
-are a lot of legitimate errors that should be caught, but it's too
-close to the final release to make the substantial changes needed to
-correct this.
-
-What's new in ZODB3 3.1 beta 3?
-===============================
-Release date: 21-Oct-2002
-
-A small extension was made to the iterator protocol. The Record
-objects, which are returned by the per-transaction iterators, contain
-a new `data_txn` attribute. It is None, unless the data contained in
-the record is a logical copy of an earlier transaction's data. For
-example, when transactional undo modifies an object, it creates a
-logical copy of the earlier transaction's data. Note that this
-provide a stronger statement about consistency than whether the data
-in two records is the same; it's possible for two different updates to
-an object to coincidentally have the same data.
-
-The restore() method was extended to take the data_txn attribute
-mentioned above as an argument. FileStorage uses the new argument to
-write a backpointer if possible.
-
-A few bugs were fixed.
-
-The setattr slot of the cPersistence C API was being initialized to
-NULL. The proper initialization was restored, preventing crashes in
-some applications with C extensions that used persistence.
-
-The return value of TimeStamp's __cmp__ method was clipped to return
-only 1, 0, -1.
-
-The restore() method was fixed to write a valid backpointer if the
-update being restored is in a version.
-
-Several bugs and improvements were made to zdaemon, which can be used
-to run the ZEO server. The parent now forwards signals to the child
-as intended. Pidfile handling was improved and the trailing newline
-was omitted.
-
-What's new in ZODB3 3.1 beta 2?
-===============================
-Release date: 4-Oct-2002
-
-A few bugs have been fixed, some that were found with the help of
-Neal Norwitz's PyChecker.
-
-The zeoup.py tool has been fixed to allow connecting to a read-only
-storage, when the --nowrite option is given.
-
-Casey Duncan fixed a few bugs in the recent changes to undoLog().
-
-The fstest.py script no longer checks that each object modified in a
-transaction has a serial number that matches the transaction id.
-This invariant is no longer maintained; several new features in the
-3.1 release depend on it.
-
-The ZopeUndo package was added. If ZODB3 is being used to run a ZEO
-server that will be used with Zope, it is usually best if the server
-and the Zope client don't share any software. The Zope undo
-framework, however, requires that a Prefix object be passed between
-client and server. To support this use, ZopeUndo was created to hold
-the Prefix object.
-
-Many bugs were fixed in ZEO, and a couple of features added. See
-`ZEO-NEWS.txt` for details.
-
-The ZODB guide included in the Doc directory has been updated. It is
-still incomplete, but most of the references to old ZODB packages have
-been removed. There is a new section that briefly explains how to use
-BTrees.
-
-The zeoup.py tool connects using a read-only connection when --nowrite
-is specifified. This feature is useful for checking on read-only ZEO
-servers.
-
-What's new in ZODB3 3.1 beta 1?
-===============================
-Release date: 12-Sep-2002
-
-We've changed the name and version number of the project, but it's
-still the same old ZODB. There have been a lot of changes since the
-last release.
-
-New ZODB cache
---------------
-
-Toby Dickenson implemented a new Connection cache for ZODB. The cache
-is responsible for pointer swizzling (translating between oids and
-Python objects) and for keeping recently used objects in memory. The
-new cache is a big improvement over the old cache. It strictly honors
-its size limit, where size is specified in number of objects, and it
-evicts objects in least recently used (LRU) order.
-
-Users should take care when setting the cache size, which has a
-default value of 400 objects. The old version of the cache often held
-many more objects than its specified size. An application may not
-perform as well with a small cache size, because the cache no longer
-exceeds the limit.
-
-Storages
---------
-
-The index used by FileStorage was reimplemented using a custom BTrees
-object. The index maps oids to file offsets, and is kept in memory at
-all times. The new index uses about 1/4 the memory of the old,
-dictionary-based index. See the module ZODB.fsIndex for details.
-
-A security flaw was corrected in transactionalUndo(). The transaction
-ids returned by undoLog() and used for transactionalUndo() contained a
-file offset. An attacker could construct a pickle with a bogus
-transaction record in its binary data, deduce the position of the
-pickle in the file from the undo log, then submit an undo with a bogus
-file position that caused the pickle to get written as a regular data
-record. The implementation was fixed so that file offsets are not
-included in the transaction ids.
-
-Several storages now have an explicit read-only mode. For example,
-passing the keyword argument read_only=1 to FileStorage will make it
-read-only. If a write operation is performed on a read-only storage,
-a ReadOnlyError will be raised.
-
-The storage API was extended with new methods that support the Zope
-Replication Service (ZRS), a proprietary Zope Corp product. We expect
-these methods to be generally useful. The methods are:
-
- - restore(oid, serialno, data, version, transaction)
-
- Perform a store without doing consistency checks. A client can
- use this method to provide a new current revision of an object.
- The ``serialno`` argument is the new serialno to use for the
- object, not the serialno of the previous revision.
-
- - lastTransaction()
-
- Returns the transaction id of the last committed transaction.
-
- - lastSerial(oid)
-
- Return the current serialno for ``oid`` or None.
-
- - iterator(start=None, stop=None)
-
- The iterator method isn't new, but the optional ``start`` and
- ``stop`` arguments are. These arguments can be used to specify
- the range of the iterator -- an inclusive range [start, stop].
-
-FileStorage is now more cautious about creating a new file when it
-believes a file does not exist. This change is a workaround for bug
-in Python versions upto and including 2.1.3. If the interpreter was
-builtin without large file support but the platform had it,
-os.path.exists() would return false for large files. The fix is to
-try to open the file first, and decide whether to create a new file
-based on errno.
-
-The undoLog() and undoInfo() methods of FileStorage can run
-concurrently with other methods. The internal storage lock is
-released periodically to give other threads a chance to run. This
-should increase responsiveness of ZEO clients when used with ZEO 2.
-
-New serial numbers are assigned consistently for abortVersion() and
-commitVersion(). When a version is committed, the non-version data
-gets a new serial number. When a version is aborted, the serial
-number for non-version data does not change. This means that the
-abortVersion() transaction record has the unique property that its
-transaction id is not the serial number of the data records.
-
-
-Berkeley Storages
------------------
-
-Berkeley storage constructors now take an optional `config` argument,
-which is an instance whose attributes can be used to configure such
-BerkeleyDB policies as an automatic checkpointing interval, lock table
-sizing, and the log directory. See bsddb3Storage/BerkeleyBase.py for
-details.
-
-A getSize() method has been added to all Berkeley storages.
-
-Berkeley storages open their environments with the DB_THREAD flag.
-
-Some performance optimizations have been implemented in Full storage,
-including the addition of a helper C extension when used with Python
-2.2. More performance improvements will be added for the ZODB 3.1
-final release.
-
-A new experimental Autopack storage was added which keeps only a
-certain amount of old revision information. The concepts in this
-storage will be folded into Full and Autopack will likely go away in
-ZODB 3.1 final. ZODB 3.1 final will also have much improved Minimal
-and Full storages, which eliminate Berkeley lock exhaustion problems,
-reduce memory use, and improve performance.
-
-It is recommended that you use BerkeleyDB 4.0.14 and PyBSDDB 3.4.0
-with the Berkeley storages. See bsddb3Storage/README.txt for details.
-
-
-BTrees
-------
-
-BTrees no longer ignore exceptions raised when two keys are compared.
-
-Tim Peters fixed several endcase bugs in the BTrees code. Most
-importantly, after a mix of inserts and deletes in a BTree or TreeSet, it
-was possible (but unlikely) for the internal state of the object to become
-inconsistent. Symptoms then varied; most often this manifested as a
-mysterious failure to find a key that you knew was present, or that
-tree.keys() would yield an object that disgreed with the tree about
-how many keys there were.
-
-If you suspect such a problem, BTrees and TreeSets now support a ._check()
-method, which does a thorough job of examining the internal tree pointers
-for consistency. It raises AssertionError if it finds any problems, else
-returns None. If ._check() raises an exception, the object is damaged,
-and rebuilding the object is the best solution. All known ways for a
-BTree or TreeSet object to become internally inconsistent have been
-repaired.
-
-Other fixes include:
-
-- Many fixes for range search endcases, including the "range search bug:"
- If the smallest key S in a bucket in a BTree was deleted, doing a range
- search on the BTree with S on the high end could claim that the range
- was empty even when it wasn't.
-
-- Zope Collector #419: repaired off-by-1 errors and IndexErrors when
- slicing BTree-based data structures. For example,
- an_IIBTree.items()[0:0] had length 1 (should be empty) if the tree
- wasn't empty.
-
-- The BTree module functions weightedIntersection() and weightedUnion()
- now treat negative weights as documented. It's hard to explain what
- their effects were before this fix, as the sign bits were getting
- confused with an internal distinction between whether the result
- should be a set or a mapping.
-
-ZEO
-----
-
-For news about ZEO2, see the file ZEO-NEWS.txt.
-
-This version of ZODB ships with two different versions of ZEO. It
-includes ZEO 2.0 beta 1, the recommended new version. (ZEO 2 will
-reach final release before ZODB3.) The ZEO 2.0 protocol is not
-compatible with ZEO 1.0, so we have also included ZEO 1.0 to support
-people already using ZEO 1.0.
-
-Other features
---------------
-
-When a ConflictError is raised, the exception object now has a
-sensible structure, thanks to a patch from Greg Ward. The exception
-now uses the following standard attributes: oid, class_name, message,
-serials. See the ZODB.POSException.ConflictError doc string for
-details.
-
-It is now easier to customize the registration of persistent objects
-with a transaction. The low-level persistence mechanism in
-cPersistence.c registers with the object's jar instead of with the
-current transaction. The jar (Connection) then registers with the
-transaction. This redirection would allow specialized Connections to
-change the default policy on how the transaction manager is selected
-without hacking the Transaction module.
-
-Empty transactions can be committed without interacting with the
-storage. It is possible for registration to occur unintentionally and
-for a persistent object to compensate by making itself as unchanged.
-When this happens, it's possible to commit a transaction with no
-modified objects. The change allows such transactions to finish even
-on a read-only storage.
-
-Two new tools were added to the Tools directory. The ``analyze.py``
-script, based on a tool by Matt Kromer, prints a summary of space
-usage in a FileStorage Data.fs. The ``checkbtrees.py`` script scans a
-FileStorage Data.fs. When it finds a BTrees object, it loads the
-object and calls the ``_check`` method. It prints warning messages
-for any corrupt BTrees objects found.
-
-Documentation
--------------
-
-The user's guide included with this release is still woefully out of date.
-
-Other bugs fixed
-----------------
-
-If an exception occurs inside an _p_deactivate() method, a traceback
-is printed on stderr. Previous versions of ZODB silently cleared the
-exception.
-
-ExtensionClass and ZODB now work correctly with a Python debug build.
-
-All C code has been fixed to use a consistent set of functions from
-the Python memory API. This allows ZODB to be used in conjunction
-with pymalloc, the default allocator in Python 2.3.
-
-zdaemon, which can be used to run a ZEO server, more clearly reports
-the exit status of its child processes.
-
-The ZEO server will reinitialize zLOG when it receives a SIGHUP. This
-allows log file rotation without restarting the server.
-
-What's new in StandaloneZODB 1.0 final?
-=======================================
-Release date: 08-Feb-2002
-
-All copyright notices have been updated to reflect the fact that the
-ZPL 2.0 covers this release.
-
-Added a cleanroom PersistentList.py implementation, which multiply
-inherits from UserDict and Persistent.
-
-Some improvements in setup.py and test.py for sites that don't have
-the Berkeley libraries installed.
-
-A new program, zeoup.py was added which simply verifies that a ZEO
-server is reachable. Also, a new program zeopack.py was added which
-connects to a ZEO server and packs it.
-
-
-What's new in StandaloneZODB 1.0 c1?
-====================================
-Release Date: 25-Jan-2002
-
-This was the first public release of the StandaloneZODB from Zope
-Corporation. Everything's new! :)
+- (3.6b4) Collector 1959: The undocumented ``transact`` module no
+ longer worked. It remains undocumented and untested, but thanks to
+ Janko Hauser it's possible that it works again ;-).
More information about the Zodb-checkins
mailing list