[elephant-devel] postmodern btree problem

[Ian Eslick]

There are two problems with calling the full initialization protocol  
of an object for all standard classes.

First, you are de-serializing an existing instance not creating a new  
one so the semantics of rerunning the initialization procedures when  
recreating a serialized object is questionable.  There was a long  
discussion on this about a year ago started by Sean Ross which led to  
the recreation protocol.

Two, under the current serializer if you store a standard class with  
an unbound slot but it has an initform, then the recreated object will  
end up with the initform value in the previously unbound slot.  This  
motivated the recent change that caused this bug.

Persistent collections are a special case as they inherit from  
persistent (so they are stored uniquely as OID references in the  
database) but are not of persistent-metaclass.  Thus they end up using  
the new standard-class recreation protocol.  In the BDB backend I  
persist data for indexed-btrees so I make that a persistent-metaclass  
and thus shared-initialize always gets called.  pm-btree is a unique  
case that wasn't handled.

My solution is to clean things up and call recreate-instance on all  
class types (standard-class and persistent-metaclass).

recreate-instance (standard-object) - does nothing
recreate-instance (persistent-object) - caching, schema upgrades,  
shared-initialize
recreate-instance (persistent-collection) - caching, shared-initialize  
(no schema support for bootstrapping purposes)

Please try out the patch that implements this, it should solve the  
special case of pm-btree recreation.  It's in the new elephant-1.0  
repository as well as unstable.

http://www.common-lisp.net/project/elephant/darcs/elephant-1.0

An additional comment below...

Thank you,
Ian

PS - Anyone know why we chose to use recreate-instance instead of  
hooking into reinitialize-instance?

On Jan 3, 2009, at 5:18 PM, Alex Mizrahi wrote:

> (defmethod recreate-instance-using-class ((class standard-class) &rest
> initargs &key &allow-other-keys)
>  (declare (ignore initargs))
>  "Simply allocate store, the state of the slots will be filled by  
> the data
> from the
>   database.  We do not want to call initialize-instance and re- 
> evaluate the
> initforms;
>   we are just fetching the object & values from the store"
>  (allocate-instance class))
>
> but i fail to understand the point -- how exactly are we "feching  
> the object
> & values from the store" for standard-class
> classes? is that some new object serialization mechanism or just an  
> error?

This is part of the deserialiation of standard-class objects; all slot  
values of standard classes that don't inherit from persistent are  
stored and restored on each deserialization.  No caching is performed.