Commit 0026bb29 authored by Tim Peters's avatar Tim Peters

Document the first (& probably last) thing to try to repair a corrupted

BTree.  This came up on the zodb-dev list last week, and Steve Alexander
pointed out that the simple fix is virtually unknown in the community.
Then again, I hope the problem is virtually unknown in the wild now too.
parent 2056e4cf
......@@ -3,6 +3,7 @@
% PersistentList
% BTrees
% Total Ordering and Persistence
% BTree Diagnostic Tools
\section{Related Modules}
......@@ -378,6 +379,25 @@ of a BTree.
BTrees and TreeSets also have a \method{_check()} method. This verifies
that the (possibly many) internal pointers in a BTree or TreeSet
are mutually consistent, and raises \exception{AssertionError} if they're
not. If a \method{_check()} method call fails, in may point to a bug
in the implementation of BTrees or conflict resolution, or may point to
database corruption.
not.
If a \function{check.check()} or \method{_check()} call fails,
it may point to a bug in the implementation of BTrees or conflict
resolution, or may point to database corruption.
Repairing a damaged BTree is usually best done by making a copy of it.
For example, if \var{self.data} is bound to a corrupted IOBTree,
\begin{verbatim}
self.data = IOBTree(self.data)
\end{verbatim}
usually suffices. If object identity needs to be preserved,
\begin{verbatim}
acopy = IOBTree(self.data)
self.data.clear()
self.data.update(acopy)
\end{verbatim}
does the same, but leaves \var{self.data} bound to the same object.
No preview for this file type
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment