This is news about ZEO protocol changes.  The promised
update of README.txt will have to be rewritten from
scratch for 3.4 (the new text in 3.3's README.txt isn't
quite right for the 3.4 release).

Rewrite ZEO protocol negotiation.

3.3 should have bumped the ZEO protocol number (new methods were
added for MVCC support), but didn't.  Untangling this is a mess.

3.3 should have bumped the ZEO protocol number (new methods were
added for MVCC support), but didn't.  Untangling this is a mess.

the most common cases (commit() and abort()) -- it's not really
obvious that shortcut spelling exist for those.

Merge checkin made from a wrong project.

Believe it or not, ZopeUndo is ZEO code, not Zope code.

r29726 | slinkp | 2005-03-30 02:11:22 -0500 (Wed, 30 Mar 2005) | 3 lines
Changed paths:
   M /Zope/trunk/lib/python/ZopeUndo/Prefix.py
   M /Zope/trunk/lib/python/ZopeUndo/tests/testPrefix.py

Merged slinkp_1726_zopeundo: avoid showing undo transactions in
the wrong folder.

Believe it or not, ZopeUndo is ZEO code, not Zope code.

r29726 | slinkp | 2005-03-30 02:11:22 -0500 (Wed, 30 Mar 2005) | 3 lines
Changed paths:
   M /Zope/trunk/lib/python/ZopeUndo/Prefix.py
   M /Zope/trunk/lib/python/ZopeUndo/tests/testPrefix.py

Merged slinkp_1726_zopeundo: avoid showing undo transactions in
the wrong folder.

checkTimeoutProvokingConflicts:  try to fix rare failures.

This always slept for 3 seconds, waiting for the storage to
disconnect.  This loses on two counts:

1. Since the timeout is set to 1 second, it typically sleeps
   longer than necessary.

2. Since there's no predicting thread and process scheduling,
   3 seconds isn't always long enough, and rare failures have
   been reported against this test.

Instead we do a polling loop now.  This typically succeeds in
a little more than a second, speeding the normal case.  The
loop will continue trying for up to a minute if not.

This always slept for 3 seconds, waiting for the storage to
disconnect.  This loses on two counts:

1. Since the timeout is set to 1 second, it typically sleeps
   longer than necessary.

2. Since there's no predicting thread and process scheduling,
   3 seconds isn't always long enough, and rare failures have
   been reported against this test.

Instead we do a polling loop now.  This typically succeeds in
a little more than a second, speeding the normal case.  The
loop will continue trying for up to a minute if not.

Change default port # from 9999 to 8100, to match zope.conf
(well, on Zope trunk anyway -- the ZEO client example appears
to have gone missing from zope.conf on Zope3 trunk).

s/zeo/ZEO/ in logger name, to match other ZEO logger names.

Assert that blobs implement IBlob.

Change names of Blob class methods that may be called when the blob object is ghosted.  We use a convention of _p_blob_whatever.

Add more txn tests... these now fail with a POSKeyError, because at some point we need to unghost a blob object which appears to retain its existing _p_blob_uncommitted and/or _p_blob_data attr values.

  on BlobFile.

- Implement __del__ on BlobFile, which attempts to close the filehandle.

- Use a weak reference to the blobfile in the BlobDataManager so as to
  not keep the blobfile alive for longer than necessary (mainly to support
  the idiom of opening a blobfile without assigning it to a name).
  It is no longer necessary to explicitly close a blobfile.

- Raise IOError if an invalid mode is passed in to Blob.open.

- Add some comments about why things are the way they are.

 

Collector #1734.  Critical bug in BTree conflict resolution.

Stop silent data loss in some BTree cases where a transaction adds
a new key to a bucket while a concurrent transaction deletes all
keys from the same bucket.

Still needs porting to 3.2 line.

 - I made the IStreamIterator not gently close itself, but rely on e.g. Medusa
   closing it.
 - The tests now document the behaviour that a user should close the file handles.

Refactor some behavior of blob and blobfile (transparent), account for append mode not failing if a file doesn't exist (it acts like write mode in this situation).

Clean up formatting to 80 cols and add a restriction noting that BlobFiles can't live beyond the transaction in which their "open" call was invoked.

Stop silent data loss in some BTree cases where a transaction adds
a new key to a bucket while a concurrent transaction deletes all
keys from the same bucket.

Still needs porting to ZODB trunk and to 3.2 line.