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.

 - Explicitly allow the different modes to be selected when opening a blob file.

 - added clean(er?) handling on cleaning up blobs on transaction boundaries and
   beeing more careful not to cause harmful states when leaking BlobFiles out
   of threads/transactions (e.g. to Medusa)

 - Added Import/Export support. Actually this is even backwards compatible.

Various Zopes probably need changes too (to avoid the new deprecation
warnings).

 - merged from head
 - added configuration methods to configure a blobfilestorage
 - made stuff work ;)

Jim (Fulton) points out that it's not entirely clear that
the new format can't be read by older ZODBs, and Tim doesn't
think it's worth the bother to find out for sure.

Added news blurbs about fsIndex improvements, and about that
.index files written by 3.4 won't be readable by earlier ZODBs.