Next: DSR Collections, Previous: DSR Handling Serialization, Up: Data Store API Reference
Persistence is implement with a metaclass and several required base classes.
Class precedence list:
persistent-metaclass, standard-class, class, specializer, metaobject, standard-object, t
Slots:
%class-schema
— initargs::schemas
The code master schema
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.
Class precedence list:
persistent, standard-object, t
Slots:
oid
— initargs::from-oid
All persistent objects have an oid
spec
— initargs::db-spec
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.)
Class precedence list:
persistent-object, persistent, standard-object, t
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?)
This is used to find and validate the connection spec maintained for in-memory persistent objects. Should we re-open the controller from the spec if it's not cached? That might be dangerous so for now we error
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.