Alex's recent question about why dup-btrees were persistent-metaclass along with a project of my own led me to the previously reported bug about deserializing btrees that had a nil in the oid slot. This is related to the reason that dup-btrees were originally persistent- metaclass.
The class recreation protocol involves a generic function that dispatches on the class, not the instance, of the object to be recreated. This means that 'persistent' vs. non-persistent isn't the easiest distinction to make. The recreation function calls a special initialization for persistent-metaclass instances (i.e. oid & spec) which wasn't getting called for btree and dup-btree.
For now, I've added a call to initialize persistent in the controller recreation protocol to handle persistent-collections properly. (for indexes and indexed-btrees this will get called twice). I probably need to think through how to make this protocol cleaner since we really want to dispatch on (subtypep class 'persistent) at recreation time.
Anyway, this case is what led to the bug about oid:nil in btrees reported by Leslie and others earlier and the fix I just pushed should take care of that bug (which means Leslie should be able to start his testing of elephant-unstable again).
Ian _______________________________________________ elephant-devel site list elephant-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/elephant-devel
