What's new on ZODB 3.7.0c1?
===========================

Packaging
---------

- (3.7.0b3) ZODB is now packaged without it's dependencies

  ZODB no longer includes copies of dependencies such as 
  ZConfig, zope.interface and so on.  It now treats these as
  dependencies.  If ZODB is installed with easy_install or
  zc.buildout, the dependencies will be installed automatically.


- (3.7.0b3) ZODB is now a buildout

  ZODB checkouts are now built and tested using zc.buildout.

ClientStorage
-------------

- (3.7b4) Added logic to avoid spurious errors from the logging system
  on exit.

- (3.7b2) Removed the "sync" mode for ClientStorage.  

  Previously, a ClientStorage could be in either "sync" mode or "async"
  mode.  Now there is just "async" mode.  There is now a dedicicated
  asyncore main loop dedicated to ZEO clients.

  Applications no-longer need to run an asyncore main loop to cause
  client storages to run in async mode.  Even if an application runs an
  asyncore main loop, it is independent of the loop used by client
  storages. 

  This addresses a test failure on Mac OS X,
  http://www.zope.org/Collectors/Zope3-dev/650, that I believe was due
  to a bug in sync mode. Some asyncore-based code was being called from
  multiple threads that didn't expect to be.

  Converting to always-async mode revealed some bugs that weren't caught
  before because the tests ran in sync mode.  These problems could
  explain some problems we've seen at times with clients taking a long
  time to reconnect after a disconnect.

  Added a partial heart beat to try to detect lost connections that
  aren't otherwise caught,
  http://mail.zope.org/pipermail/zodb-dev/2005-June/008951.html, by
  perioidically writing to all connections during periods of inactivity.

Connection management
---------------------

- (3.7a1) 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.

DemoStorage
-----------

- (3.7a1) 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).

Documentation
-------------

- (3.7a1) Thanks to Stephan Richter for converting many of the doctest
  files to ReST format.  These are now chapters in the Zope 3 apidoc too.

IPersistent
-----------

- (3.7a1) The documentation for ``_p_oid`` now specifies the concrete
  type of oids (in short, an oid is either None or a non-empty string).

Testing
-------

- (3.7b2) Fixed test-runner output truncation.

  A bug was fixed in the test runner that caused result summaries to be
  omitted when running on Windows.

Tools
-----

- (3.7b2) Fixed bug in 'fsrefs.py' which caused it to report erroneous
  "missing" classes.


- (3.7a1) 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.7a1) Suppressed warnings about signedness of characters when
  compiling under GCC 4.0.x.  See http://www.zope.org/Collectors/Zope/2027.

- (3.7a1) Support for 64-bit integer keys and values has been provided as a
  compile-time option.

Connection
----------

- (3.7a1) An optimization for loading non-current data (MVCC) was
  inadvertently disabled in ``_setstate()``; this has been repaired.

persistent
----------

- (3.7a1) Suppressed warnings about signedness of characters when
  compiling under GCC 4.0.x.  See http://www.zope.org/Collectors/Zope/2027.

- (3.7a1) PersistentMapping was inadvertently pickling volatile attributes
  (http://www.zope.org/Collectors/Zope/2052).

After Commit hooks
------------------

- (3.7a1) Transaction objects have a new method,
  ``addAfterCommitHook(hook, *args, **kws)``.  Hook functions
  registered with a transaction are called after the transaction
  commits or aborts. For example, one might want to launch non
  transactional or asynchrnonous code after a successful, or aborted,
  commit. See ``test_afterCommitHook()`` in
  ``transaction/tests/test_transaction.py`` for a tutorial doctest,
  and the ``ITransaction`` interface for details.
