[ZODB-Dev] checkbtrees question.

[Tim Peters]

[Syver Enstad, running checkbtrees.py]
...
> I am really glad that the total/found line isn't a problem, because
> the database is really simple just a int to object Btree with
> simple objects that has no links to other objects (other than built in
> types) and I couldn't understand what could be a problem with it.

It's not that simple, though:  even a single IIBTree (integer keys and
integer values) can be composed of any number of distinct persistent objects
internally.  It may have "tree" in its name, but a BTree isn't a tree, it's
a more general DAG (directed acyclic graph) of multiple persistent objects
under the covers, with "bucket nodes" and layers of "parent nodes"
cross-connected in three different ways.  While this complexity isn't
normally visible to you, it's there under the covers, and is what makes
ZODB's BTrees scalable.

There are no currently known bugs of this nature, but in the years I've been
poking at this stuff there have been about a half dozen different bugs in
ZODB, and in ZEO, mostly involving invalidation races, that could lead to
various kinds of fatal inconsistency among the internal nodes of a single
BTree (or TreeSet -- much the same under the covers).  checkbtrees.py was
written in response to this, so people could check older databases for the
kinds of BTree damage those bugs caused.  We never hear about new cases
anymore, since the last <wink> bug was fixed.