[Checkins] SVN: ZODB3/trunk/CHANGES.txt Changes only by reference.

jim cvs-admin at zope.org
Mon Nov 19 20:04:15 UTC 2012


Log message for revision 128354:
  Changes only by reference.
  

Changed:
  U   ZODB3/trunk/CHANGES.txt

-=-
Modified: ZODB3/trunk/CHANGES.txt
===================================================================
--- ZODB3/trunk/CHANGES.txt	2012-11-19 19:50:40 UTC (rev 128353)
+++ ZODB3/trunk/CHANGES.txt	2012-11-19 20:04:14 UTC (rev 128354)
@@ -2,381 +2,20 @@
  Change History
 ================
 
-3.11.0a1 (2012-??-??)
+3.11.0a1 (2012-11-19)
 =====================
 
 New Features
 ------------
 
-- ZODB3 has been split into 3 separate packages:
+- ZODB3 has been split into 4 separate packages:
 
-  - persistent
-  - ZODB
-  - ZEO
+  - persistent 4.0
+  - BTrees 4.0
+  - ZODB 4.0
+  - ZEO 4.0
 
   The ZODB3 distribution is simply a meta-distribution, for backward
-  compatibility, that depends on the other 3.
+  compatibility, that depends the others.
 
-- ZODB no longer depends on zope.event.  It now uses ZODB.event, which
-  uses zope.event if it is installed.  You can override
-  ZODB.event.notify to provide your own event handling, although
-  zope.event is recommended.
-
-- BTrees allowed object keys with insane comparison. (Comparison
-  inherited from object, which compares based on in-process address.)
-  Now BTrees raise TypeError if an attempt is made to save a key with
-  comparison inherited from object. (This doesn't apply to old-style
-  class instances.)
-
-- Storage servers now emit Serving and Closed events so subscribers
-  can discover addresses when dynamic port assignment (bind to port 0)
-  is used. This could, for example, be used to update address
-  information in a ZooKeeper database.
-
-- Client storagers have a method, new_addr, that can be used to change
-  the server address(es). This can be used, for example, to update a
-  dynamically determined server address from information in a
-  ZooKeeper database.
-
-Bugs Fixed
-----------
-
-- Ensured that the export file and index file created by ``repozo`` share
-  the same timestamp.
-
-  https://bugs.launchpad.net/zodb/+bug/993350
-
-- Pinned the ``transaction`` and ``manuel`` dependencies to Python 2.5-
-  compatible versions when installing under Python 2.5.
-
-3.10.5 (2011-11-19)
-===================
-
-Bugs Fixed
-----------
-
-- Conflict resolution failed when state included cross-database
-  persistent references with classes that couldn't be imported.
-
-3.10.4 (2011-11-17)
-===================
-
-Bugs Fixed
-----------
-
-- Conflict resolution failed when state included persistent references
-  with classes that couldn't be imported.
-
-3.10.3 (2011-04-12)
-===================
-
-Bugs Fixed
-----------
-
-- "activity monitor not updated for subconnections when connection
-  returned to pool"
-
-  https://bugs.launchpad.net/zodb/+bug/737198
-
-- "Blob temp file get's removed before it should",
-  https://bugs.launchpad.net/zodb/+bug/595378
-
-  A way this to happen is that a transaction is aborted after the
-  commit process has started. I don't know how this would happen in
-  the wild.
-
-  In 3.10.3, the ZEO tpc_abort call to the server is changed to be
-  synchronous, which should address this case. Maybe there's another
-  case.
-
-
-Performance enhancements
-------------------------
-
-- Improved ZEO client cache implementation to make it less likely to
-  evict objects that are being used.
-
-- Small (possibly negligable) reduction in CPU in ZEO storage servers
-  to service object loads and in networking code.
-
-3.10.2 (2011-02-12)
-===================
-
-Bugs Fixed
-----------
-
-- 3.10 introduced an optimization to try to address BTree conflict
-  errors arrising for basing BTree keys on object ids. The
-  optimization caused object ids allocated in aborted transactions to
-  be reused. Unfortunately, this optimzation led to some rather
-  severe failures in some applications.  The symptom is a conflict
-  error in which one of the serials mentioned is zero.  This
-  optimization has been removed.
-
-  See (for example): https://bugs.launchpad.net/zodb/+bug/665452
-
-- ZEO server transaction timeouts weren't logged as critical.
-
-  https://bugs.launchpad.net/zodb/+bug/670986
-
-3.10.1 (2010-10-27)
-===================
-
-Bugs Fixed
-----------
-
-- When a transaction rolled back a savepoint after adding objects and
-  subsequently added more objects and committed, an error could be
-  raised "ValueError: A different object already has the same oid"
-  causing the transaction to fail. Worse, this could leave a database
-  in a state where subsequent transactions in the same process would
-  fail.
-
-  https://bugs.launchpad.net/zodb/+bug/665452
-
-- Unix domain sockets didn't work for ZEO (since the addition of IPv6
-  support). https://bugs.launchpad.net/zodb/+bug/663259
-
-- Removed a missfeature that can cause performance problems when using
-  an external garbage collector with ZEO.  When objects were deleted
-  from a storage, invalidations were sent to clients. This makes no
-  sense.  It's wildly unlikely that the other connections/clients have
-  copies of the garbage.  In normal storage garbage collection, we
-  don't send invalidations. There's no reason to send them when an
-  external garbage collector is used.
-
-- ZEO client cache simulation misshandled invalidations
-  causing incorrect statistics and errors.
-
-3.10.0 (2010-10-08)
-===================
-
-New Features
-------------
-
-- There are a number of performance enhancements for ZEO storage
-  servers.
-
-- FileStorage indexes use a new format. They are saved and loaded much
-  faster and take less space. Old indexes can still be read, but new
-  indexes won't be readable by older versions of ZODB.
-
-- The API for undoing multiple transactions has changed.  To undo
-  multiple transactions in a single transaction, pass a list of
-  transaction identifiers to a database's undoMultiple method. Calling a
-  database's undo method multiple times in the same transaction now
-  raises an exception.
-
-- The ZEO protocol for undo has changed.  The only user-visible
-  consequence of this is that when ZODB 3.10 ZEO servers won't support
-  undo for older clients.
-
-- The storage API (IStorage) has been tightened. Now, storages should
-  raise a StorageTransactionError when invalid transactions are passed
-  to tpc_begin, tpc_vote, or tpc_finish.
-
-- ZEO clients (``ClientStorage`` instances) now work in forked processes,
-  including those created via ``multiprocessing.Process`` instances.
-
-- Broken objects now provide the IBroken interface.
-
-- As a convenience, you can now pass an integer port as an address to
-  the ZEO ClientStorage constructor.
-
-- As a convenience, there's a new ``client`` function in the ZEO
-  package for constructing a ClientStorage instance.  It takes the
-  same arguments as the ClientStorage constructor.
-
-- DemoStorages now accept constructor athuments, close_base_on_close
-  and close_changes_on_close, to control whether underlying storages
-  are closed when the DemoStorage is closed.
-
-  https://bugs.launchpad.net/zodb/+bug/118512
-
-- Removed the dependency on zope.proxy.
-
-- Removed support for the _p_independent mini framework, which was
-  made moot by the introduction of multi-version concurrency control
-  several years ago.
-
-- Added support for the transaction retry convenience
-  (transaction-manager attempts method) introduced in the
-  ``transaction`` 1.1.0 release.
-
-- Enhanced the database opening conveniences:
-
-  - You can now pass storage keyword arguments to ZODB.DB and
-    ZODB.connection.
-
-  - You can now pass None (rather than a storage or file name) to get
-    a database with a mapping storage.
-
-- Databases now warn when committing very large records (> 16MB).
-  This is to try to warn people of likely design mistakes.  There is a
-  new option (large_record_size/large-record-size) to control the
-  record size at which the warning is issued.
-
-- Added support for wrapper storages that transform pickle data.
-  Applications for this include compression and encryption.  An
-  example wrapper storage implementation, ZODB.tests.hexstorage, was
-  included for testing.
-
-  It is important that storage implementations not assume that
-  storages contain pickles.  Renamed IStorageDB to IStorageWrapper and
-  expanded it to provide methods for transforming and untransforming
-  data records.  Storages implementations should use these methods to
-  get pickle data from stored records.
-
-- Deprecated ZODB.interfaces.StorageStopIteration.  Storage
-  iterator implementations should just raise StopIteration, which
-  means they can now be implemented as generators.
-
-- The filestorage packer configuration option noe accepts values of
-  the form ``modname:expression``, allowing the use of packer
-  factories with options.
-
-- Added a new API that allows applications to make sure that current
-  data are read. For example, with::
-
-    self._p_jar.readCurrent(ob)
-
-  A conflict error will be raised if the version of ob read by the
-  transaction isn't current when the transaction is committed.
-
-  Normally, ZODB only assures that objects read are consistent, but not
-  necessarily up to date.  Checking whether an object is up to date is
-  important when information read from one object is used to update
-  another.
-
-  BTrees are an important case of reading one object to update
-  another.  Internal nodes are read to decide which leave notes are
-  updated when a BTree is updated.  BTrees now use this new API to
-  make sure that internal nodes are up to date on updates.
-
-- When transactions are aborted, new object ids allocated during the
-  transaction are saved and used in subsequent transactions. This can
-  help in situations where object ids are used as BTree keys and the
-  sequential allocation of object ids leads to conflict errors.
-
-- ZEO servers now support a server_status method for for getting
-  information on the number of clients, lock requests and general
-  statistics.
-
-- ZEO clients now support a client_label constructor argument and
-  client-label configuration-file option to specify a label for a
-  client in server logs. This makes it easier to identify specific
-  clients corresponding to server log entries, especially when there
-  are multiple clients originating from the same machine.
-
-- Improved ZEO server commit lock logging.  Now, locking activity is
-  logged at the debug level until the number of waiting lock requests
-  gets above 3.  Log at the critical level when the number of waiting
-  lock requests gets above 9.
-
-- The file-storage backup script, repozo, will now create a backup
-  index file if an output file name is given via the --output/-o
-  option.
-
-- Added a '--kill-old-on-full' argument to the repozo backup options:
-  if passed, remove any older full or incremental backup files from the
-  repository after doing a full backup.
-  (https://bugs.launchpad.net/zope2/+bug/143158)
-
-- The mkzeoinst script has been moved to a separate project:
-
-    http://pypi.python.org/pypi/zope.mkzeoinstance
-
-  and is no-longer included with ZODB.
-
-- Removed untested unsupported dbmstorage fossile.
-
-- ZEO servers no longer log their pids in every log message. It's just
-  not interesting. :)
-
-Bugs fixed
-----------
-
-- When a pool timeout was specified for a database and old connections
-  were removed due to timing out, an error occured due to a bug in the
-  connection cleanup logic.
-
-- When multi-database connections were no longer used and cleaned up,
-  their subconnections weren't cleaned up properly.
-
-- ZEO didn't work with IPv6 addrsses.
-  Added IPv6 support contributed by Martin v. Löwis.
-
-- A file storage bug could cause ZEO clients to have incorrect
-  information about current object revisions after reconnecting to a
-  database server.
-
-- Updated the 'repozo --kill-old-on-full' option to remove any '.index'
-  files corresponding to backups being removed.
-
-- ZEO extension methods failed when a client reconnected to a
-  storage. (https://bugs.launchpad.net/zodb/+bug/143344)
-
-- Clarified the return Value for lastTransaction in the case when
-  there aren't any transactions.  Now a string of 8 nulls (aka "z64")
-  is specified.
-
-- Setting _p_changed on a blob wo actually writing anything caused an
-  error. (https://bugs.launchpad.net/zodb/+bug/440234)
-
-- The verbose mode of the fstest was broken.
-  (https://bugs.launchpad.net/zodb/+bug/475996)
-
-- Object ids created in a savepoint that is rolled back wren't being
-  reused. (https://bugs.launchpad.net/zodb/+bug/588389)
-
-- Database connections didn't invalidate cache entries when conflict
-  errors were raised in response to checkCurrentSerialInTransaction
-  errors. Normally, this shouldn't be a problem, since there should be
-  pending invalidations for these oids which will cause the object to
-  be invalidated. There have been issues with ZEO persistent cache
-  management that have caused out of date data to remain in the cache.
-  (It's possible that the last of these were addressed in the
-  3.10.0b5.) Invalidating read data when there is a conflict error
-  provides some extra insurance.
-
-- The interface, ZODB.interfaces.IStorage was incorrect. The store
-  method should never return a sequence of oid and serial pairs.
-
-- When a demo storage push method was used to create a new demo
-  storage and the new storage was closed, the original was
-  (incorrectly) closed.
-
-- There were numerous bugs in the ZEO cache tracing and analysis code.
-  Cache simulation, while not perfect, seems to be much more accurate
-  now than it was before.
-
-  The ZEO cache trace statistics and simulation scripts have been
-  given more descriptive names and moved to the ZEO scripts package.
-
-- BTree sets and tree sets didn't correctly check values passed to
-  update or to constructors, causing Python to exit under certain
-  circumstances.
-
-- Fixed bug in copying a BTrees.Length instance.
-  (https://bugs.launchpad.net/zodb/+bug/516653)
-
-- Fixed a serious bug that caused cache failures when run
-  with Python optimization turned on.
-
-  https://bugs.launchpad.net/zodb/+bug/544305
-
-- When using using a ClientStorage in a Storage server, there was a
-  threading bug that caused clients to get disconnected.
-
-- On Mac OS X, clients that connected and disconnected quickly could
-  cause a ZEO server to stop accepting connections, due to a failure
-  to catch errors in the initial part of the connection process.
-
-  The failure to properly handle exceptions while accepting
-  connections is potentially problematic on other platforms.
-
-  Fixes: https://bugs.launchpad.net/zodb/+bug/135108
-
-- Object state management wasn't done correctly when classes
-  implemented custom _p_deavtivate methods.
-  (https://bugs.launchpad.net/zodb/+bug/185066)
+See the changes logs in the other packages.



More information about the checkins mailing list