[Zodb-checkins] SVN: ZODB/trunk/HISTORY.txt Added a history file with old news.

Jim Fulton jim at zope.com
Tue Jul 18 14:16:12 EDT 2006


Log message for revision 69181:
  Added a history file with old news.
  

Changed:
  A   ZODB/trunk/HISTORY.txt

-=-
Added: ZODB/trunk/HISTORY.txt
===================================================================
--- ZODB/trunk/HISTORY.txt	2006-07-18 18:16:01 UTC (rev 69180)
+++ ZODB/trunk/HISTORY.txt	2006-07-18 18:16:10 UTC (rev 69181)
@@ -0,0 +1,3110 @@
+What's new in ZODB3 3.6.2?
+==========================
+Release date: 15-July-2006
+
+
+DemoStorage
+-----------
+
+- (3.6.2) DemoStorage was unable to wrap base storages who did not have
+          an '_oid' attribute:  most notably, ZEO.ClientStorage
+          (http://www.zope.org/Collectors/Zope/2016).
+
+Following is combined news from internal releases (to support ongoing
+Zope2 / Zope3 development).  These are the dates of the internal releases:
+
+- 3.6.1 27-Mar-2006
+- 3.6.0 05-Jan-2006
+- 3.6b6 01-Jan-2006
+- 3.6b5 18-Dec-2005
+- 3.6b4 04-Dec-2005
+- 3.6b3 06-Nov-2005
+- 3.6b2 25-Oct-2005
+- 3.6b1 24-Oct-2005
+- 3.6a4 07-Oct-2005
+- 3.6a3 07-Sep-2005
+- 3.6a2 06-Sep-2005
+- 3.6a1 04-Sep-2005
+
+Removal of Features Deprecated in ZODB 3.4
+------------------------------------------
+
+(3.6b2) ZODB 3.6 no longer contains features officially deprecated in the
+ZODB 3.4 release.  These include:
+
+- ``get_transaction()``.  Use ``transaction.get()`` instead.
+  ``transaction.commit()`` is a shortcut spelling of
+  ``transaction.get().commit()``, and ``transaction.abort()``
+  of ``transaction.get().abort()``.  Note that importing ZODB no longer
+  installs ``get_transaction`` as a name in Python's ``__builtin__``
+  module either.
+
+- The ``begin()`` method of ``Transaction`` objects.  Use the ``begin()``
+  method of a transaction manager instead.  ``transaction.begin()`` is
+  a shortcut spelling to call the default transaction manager's ``begin()``
+  method.
+
+- The ``dt`` argument to ``Connection.cacheMinimize()``.
+
+- The ``Connection.cacheFullSweep()`` method.  Use ``cacheMinimize()``
+  instead.
+
+- The ``Connection.getTransaction()`` method.  Pass a transaction manager
+  to ``DB.open()`` instead.
+
+- The ``Connection.getLocalTransaction()`` method.  Pass a transaction
+  manager to ``DB.open()`` instead.
+
+- The ``cache_deactivate_after`` and ``version_cache_deactivate_after``
+  arguments to the ``DB`` constructor.
+
+- The ``temporary``, ``force``, and ``waitflag`` arguments
+  to ``DB.open()``.  ``DB.open()`` no longer blocks (there's no longer
+  a fixed limit on the number of open connections).
+
+- The ``transaction`` and ``txn_mgr``arguments to ``DB.open()``.  Use
+  the ``transaction_manager`` argument instead.
+
+- The ``getCacheDeactivateAfter``, ``setCacheDeactivateAfter``,
+  ``getVersionCacheDeactivateAfter`` and ``setVersionCacheDeactivateAfter``
+  methods of ``DB``.
+
+Persistent
+----------
+
+- (3.6.1) Suppressed warnings about signedness of characters when
+  compiling under GCC 4.0.x.  See http://www.zope.org/Collectors/Zope/2027.
+
+- (3.6a4) ZODB 3.6 introduces a change to the basic behavior of Persistent
+  objects in a particular end case.  Before ZODB 3.6, setting
+  ``obj._p_changed`` to a true value when ``obj`` was a ghost was ignored:
+  ``obj`` remained a ghost, and getting ``obj._p_changed`` continued to
+  return ``None``.  Starting with ZODB 3.6, ``obj`` is activated instead
+  (unghostified), and its state is changed from the ghost state to the
+  changed state.  The new behavior is less surprising and more robust.
+
+- (3.6b5) The documentation for ``_p_oid`` now specifies the concrete
+  type of oids (in short, an oid is either None or a non-empty string).
+
+Commit hooks
+------------
+
+- (3.6a1) The ``beforeCommitHook()`` method has been replaced by the new
+  ``addBeforeCommitHook()`` method, with a more-robust signature.
+  ``beforeCommitHook()`` is now deprecated, and will be removed in ZODB 3.8.
+  Thanks to Julien Anguenot for contributing code and tests.
+
+Connection management
+---------------------
+
+- (3.6b6) When more than ``pool_size`` connections have been closed,
+  ``DB`` forgets the excess (over ``pool_size``) connections closed first.
+  Python's cyclic garbage collection can take "a long time" to reclaim them
+  (and may in fact never reclaim them if application code keeps strong
+  references to them), but such forgotten connections can never be opened
+  again, so their caches are now cleared at the time ``DB`` forgets them.
+  Most applications won't notice a difference, but applications that open
+  many connections, and/or store many large objects in connection caches,
+  and/or store limited resources (such as RDB connections) in connection
+  caches may benefit.
+
+ZEO
+---
+
+- (3.6a4) Collector 1900.  In some cases of pickle exceptions raised by
+  low-level ZEO communication code, callers of ``marshal.encode()`` could
+  attempt to catch an exception that didn't actually exist, leading to an
+  erroneous ``AttributeError`` exception.  Thanks to Tres Seaver for the
+  diagnosis.
+
+BaseStorage
+-----------
+
+- (3.6a4) Nothing done by ``tpc_abort()`` should raise an exception.
+  However, if something does (an error case), ``BaseStorage.tpc_abort()``
+  left the commit lock in the acquired state, causing any later attempt
+  to commit changes hang.
+
+Multidatabase
+-------------
+
+- (3.6b1) The ``database_name`` for a database in a multidatabase
+  collection can now be specified in a config file's ``<zodb>`` section,
+  as the value of the optional new ``database_name`` key.  The
+  ``.databases`` attribute cannot be specified in a config file, but
+  can be passed as the optional new ``databases`` argument to the
+  ``open()`` method of a ZConfig factory for type ``ZODBDatabase``.
+  For backward compatibility, Zope 2.9 continues to allow using the
+  name in its ``<zodb_db name>`` config section as the database name
+  (note that ``<zodb_db>`` is defined by Zope, not by ZODB -- it's a
+  Zope-specific extension of ZODB's ``<zodb>`` section).
+
+PersistentMapping
+-----------------
+
+- (3.6.1) PersistentMapping was inadvertently pickling volatile attributes
+  (http://www.zope.org/Collectors/Zope/2052).
+
+- (3.6b4) ``PersistentMapping`` makes changes by a ``pop()`` method call
+  persistent now (http://www.zope.org/Collectors/Zope/2036).
+
+- (3.6a1) 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.
+
+Tools
+-----
+
+- (3.6b5) The changeover from zLOG to the logging module means that some
+  tools need to perform minimal logging configuration themselves. Changed
+  the zeoup script to do so and thus enable it to emit error messages.
+
+BTrees
+------
+
+- (3.6.1) Suppressed warnings about signedness of characters when
+  compiling under GCC 4.0.x.  See http://www.zope.org/Collectors/Zope/2027.
+
+- (3.6a1) BTrees and Buckets now implement the ``setdefault()`` and ``pop()``
+  methods. These are exactly like Python's dictionary methods of the same
+  names, except that ``setdefault()`` requires both arguments (and Python is
+  likely to change to require both arguments too -- defaulting the
+  ``default`` argument to ``None`` has no viable use cases).  Thanks to
+  Ruslan Spivak for contributing code, tests, and documentation.
+
+- (3.6a1) 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.
+
+ZopeUndo
+--------
+
+- (3.6a4) Collector 1810. A previous bugfix (#1726) broke listing undoable
+  transactions for users defined in a non-root acl_users folder. Zope logs
+  a acl_users path together with a username (separated by a space) and this
+  previous fix failed to take this into account.
+
+Connection
+----------
+
+- (3.6b5) An optimization for loading non-current data (MVCC) was
+  inadvertently disabled in ``_setstate()``; this has been repaired.
+
+Documentation
+-------------
+
+- (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
+-----------
+
+- (3.6a1) The source code for the old ExtensionClass-based Persistence
+  package moved, from ZODB to the Zope 2.9 development tree.  ZODB 3.5
+  makes no use of Persistence, and, indeed, the Persistence package could
+  not be compiled from a ZODB release, since some of the C header files
+  needed appear only in Zope.
+
+- (3.6a3) Re-added the ``zeoctl`` module, for the same reasons
+  ``mkzeoinst`` was re-added (see below).
+
+- (3.6a2) 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.
+
+``transact``
+------------
+
+- (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 ;-).
+
+What's new in ZODB3 3.5.1?
+==========================
+Release date: 26-Sep-2005
+
+Following is combined news from internal releases (to support ongoing
+Zope3 development).  These are the dates of the internal releases:
+
+- 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.
+
+ZopeUndo
+--------
+
+- (3.5.1) Collector 1810. A previous bugfix (#1726) broke listing undoable
+  transactions for users defined in a non-root acl_users folder. Zope logs
+  a acl_users path together with a username (separated by a space) and this
+  previous fix failed to take this into account.
+
+
+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.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
+------------
+
+- (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! :)


Property changes on: ZODB/trunk/HISTORY.txt
___________________________________________________________________
Name: svn:eol-style
   + native



More information about the Zodb-checkins mailing list