Persistence is implement with a metaclass and several required base classes.
Metaclass for persistent classes. Use this metaclass to define persistent classes. All slots are persistent by default; use the :transient flag otherwise. Slots can also be indexed for by-value retrieval.
All persistent objects have an oid
Persistent objects use a spec pointer to identify which store they are connected to
Abstract superclass for all persistent classes (common to both user-defined classes and Elephant-defined objects such as collections.)
Superclass for all user-defined persistent classes. This is automatically inherited if you use the persistent-metaclass metaclass. This allows specialization of functions for user objects that would not be appropriate for Elephant objects such as persistent collections
Persistent objects can be queries for their home store controller so that functions such as map-btree do not need a store-controller argument. (NOTE: Should this function be user visible?)
All objects require a unique object identifier. During new object creation the data store is asked to produce a unique id.
These functions are called by the metaclass protocol to implement the appropriate operations on persistent class slots. Unless protected by a transaction, the side effects of these functions should be atomic, persistent and visible to other threads on completion.