This version of Elephant supports migration between store controllers of any backend type.
migrate5 are demonstrations of this
There is a single generic function
migrate that is used to copy
different object types to a target repository. It is assumed that typically
migrate will be called on two repositories and all live objects (those
reachable in the root or class-root) will be copied to the target repository
via recursive calls to migrate for specific objects.
When persistent instances are copied, their internal pointer will be updated to point to the new repository so after migration the lisp image should be merely updated to refer to the target repository in the *store-controller* variable or whatever variable the application is using to store the primary controller instance.
There are some limitations to the current migration implementation:
Users can customize migration if they create unusual datastructures that
are not automatically supported by the existing
For example, a datastructure that stores only object OIDs instead of
serialized object references will need to overload migrate to ensure
that all referenced objects are in fact copied (otherwise the OIDs will
just be treated as fixnums potentially leaving dangling references.
To customize migration overload a version of migrate to specialize on your specific persistent class type.
(defmethod migrate ((dst store-controller) (src my-class)))
In the body of this method you can call
to get a destination repository object with all the slots copied over
to the target repository which you can then overwrite. To avoid the
default persistent slot copying, bind the dynamic variable
*inhibit-slot-writes* in your user method using
with-inhibited-slot-copy a convenience macro.