Persistent objects

[Andreas Paepcke <paepcke%hplap@hplabs.HP.COM>]

We have developed PCLOS which makes CLOS objects persistent on multiple
databases. The system may have instances that are transient, or that are
stored in a variety of databases, all in one session. Of Larry's choices we
have picked the metaclass solution and have been very happy with it. Once
you have gone through somewhat difficult-to-read code to understand how the
metaclass works, this mechanism is marvelously powerful and allows for
elegant, integrated solutions.

The PCLOS imlementation is similar to what Gregor outlines. The object id,
however, doesn't show up as a slot which would be seen by the user through
'describe'. Information like the object id is instead hidden in some fields
at the beginning of the slot value vector.  This is one of the tricks that
are easy to do through a new metaclass and it adds to the transparency of
persistence. DB-specific functional capabilities are furthermore added by
having the metaclass slip a superclass into the cpl of all classes.

PCLOS turns the allocation of space for slot values in memory to its
advantage: That place is used whenever an object is cached in from the
database.  Slot-value-using-class and its value-setting partner then either
go to the database for slot access to non-cached objects, or they access
slots the same general way the standard metaclass does when operating on
cached or transient objects. We call the in-memory object representations
"husks".  One advantage of this scheme beyond caching convenience is that
it is real simple and natural to mix transient and persistent objects in
one session because they look so similar.

The problem with slot access optimization by methods of superclasses of a
different metaclass is insidious. It has caused me grief until I understood
it. Unfortunately the solution Gregor suggests - of simply not allowing
such inheritance - is problematic in the real world. We have encountered
several cases where we needed to inherit in this way and the superclasses
could not be touched because we get them canned. There was originally talk
about an "unoptimize" capability which would presumably go through a method
and turn all the optimized slot accesses into calls to slot-value. I am not
sure how that could possibly be done on binaries, but I refuse to give up
my believe in magic. So I am looking for that as a way out of the dilemma.

Another advantage to using the metaclass is the fact that you can begin to
keep information in the class objects. This is needed for various reasons,
support for persistence of class-allocated slots, among others.

Andreas