What's new in ZODB3 3.6.1? ========================== Release date: 27-Mar-2006 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 ```` 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 ```` config section as the database name (note that ```` is defined by Zope, not by ZODB -- it's a Zope-specific extension of ZODB's ```` 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. - (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 ;-).