[Zodb-checkins] CVS: ZODB3 - NEWS.txt:188.8.131.52
tim.one at comcast.net
Fri Feb 25 15:31:34 EST 2005
Update of /cvs-repository/ZODB3
In directory cvs.zope.org:/tmp/cvs-serv24962
Stop believing the maximum oid cached in a FileStorage's .index file.
This is a critical bugfix, although the problems it addresses are
(a) rare; and, (b) not entirely fixed yet (more checkins to come).
The true max oid is found efficiently now by exploiting the recently-added
fsIndex.maxKey() method (which was, of course, added for this purpose).
Also fix that the .index file could get updated on disk when the
FileStorage was opened in read-only mode. The code was trying to prevent
this, but missed the most obvious rewrite path.
Incidentally improved many obsolete and/or incorrect comments.
=== ZODB3/NEWS.txt 184.108.40.206 => 220.127.116.11 ===
--- ZODB3/NEWS.txt:18.104.22.168 Thu Feb 24 17:41:25 2005
+++ ZODB3/NEWS.txt Fri Feb 25 15:31:04 2005
@@ -28,6 +28,32 @@
depending on platform, and should suffer far fewer (if any) intermittent
"timed out waiting for storage to connect" failures.
+- A FileStorage's index file tried to maintain the index's largest oid as a
+ separate piece of data, incrementally updated over the storage's lifetime.
+ This scheme was more complicated than necessary, so was also more brittle
+ and slower than necessary. It indirectly participated in a rare but
+ critical bug: when a FileStorage was created via
+ ``copyTransactionsFrom()``, the "maximum oid" saved in the index file was
+ always 0. Use that FileStorage, and it could then create "new" oids
+ starting over at 0 again, despite that those oids were already in use by
+ old objects in the database. Packing a FileStorage has no reason to
+ try to update the maximum oid in the index file either, so this kind of
+ damage could (and did) persist even across packing.
+ The index file's maximum-oid data is ignored now, but is still written
+ out so that ``.index`` files can be read by older versions of ZODB.
+ Finding the true maximum oid is done now by exploiting that the main
+ index is really a kind of BTree (long ago, this wasn't true), and finding
+ the largest key in a BTree is inexpensive.
+- A FileStorage's index file could be updated on disk even if the storage
+ was opened in read-only mode. That bug has been repaired.
+- An efficient ``maxKey()`` implementation was added to class ``fsIndex``.
Pickle (in-memory Connection) Cache
More information about the Zodb-checkins