Tim Peters wrote:
If a client restarted during the day, wouldn't you find evidence of that in
This is all there is to it, where Data.fs has a single large OOBTree
attached as to the root under key "tree":
st = ZODB.FileStorage.FileStorage('Data.fs')
db = ZODB.DB(st)
cn = db.open()
rt = cn.root()
tree = rt['tree']
<extension class BTrees.OOBTree.OOBTree at 00C99660>
cn.close() # DON'T BLINK
Yep, I understand the mechanics, just not where it's happening ;-)
BTW, because we didn't see ConnectionStateError at the time cn.close() was
done, we know that no objects loaded from the Connection were left in a
That sounds like a good thing :-)
BTW, I haven't seen a traceback associated with your "shouldn't load state"
problems. Do any exist? (I understand they may not be logged, I'm
wondering if you can see them from the ZMI. If it _is_ unintentional
caching, a traceback could be invaluable.)
Do you mind if I apply the following patch to the ZODB trunk?
--- Connection.py (revision 39510)
+++ Connection.py (working copy)
@@ -725,7 +725,7 @@
if self._opened is None:
msg = ("Shouldn't load state for %s "
"when the connection is closed" % oid_repr(oid))
@@ -734,7 +734,7 @@
self._log.error("Couldn't load state for %s", oid_repr(oid),
def _setstate(self, obj):
(the second bit should happen anyway ;-) )
Once this is done, how does it wend its way into a Zope 2.8 release?
What other branches / changes.txt files should I merge to?
Simplistix - Content Management, Zope & Python Consulting
For more information about ZODB, see the ZODB Wiki:
ZODB-Dev mailing list - ZODB-Dev@zope.org