Previous: Transaction API, Up: User API Reference
Upgrade is a call to Migrate with checks for compatability. The migrate methods are included here in case you wish to develop a more specific “partial upgrade” or “partial migrate” of data from one store to another instead of using the top-level copy which migrates all live objects.
Given an open store controller from a prior version, open a new store specified by spec and migrate the data from the original store to the new one, upgrading it to the latest version
Migrate an object from the src object, collection or controller to the dst controller. Returns a copy of the object in the new store so you can drop it into a parent object or the root of the dst controller
Migrate each hash element as the types are non-uniform
We really only need to handle arrays of type 't' that point to other objects; fixnum, float, etc array can just be written to the new store but we don't bother to optimize here
warning:
This doesn't work for circular lists
Migrate pathname as just return itself
Walks structure slot values and ensures that any persistent references are written back into the slot pointint to the new store
If we have persistent objects that are unindexed and
only
stored in a standard object slot that is referenced from the root, then it will only be copied by recursing through the slot substructure just as the serializer will, but copying any persistent objects found
Also copy the inverse indices for indexed btrees
Copy an index and it's contents to the target repository
Migrate a persistent object and apply a binary (lambda (dst src) ...) function to the new object. Users can override migrate by creating a function that calls the default copy and then does stuff with the slot values. A dynamic variable: *inhibit-slot-copy* can be bound in the caller to keep the new object from having its slots copied
This method ensures that we reset duplicate object detection over the store-controller
This method ensures that we reset duplicate object detection over the store-controller
This provides some sanity checking that we aren't trying to copy to the same controller. We also need to be careful about deadlocking our transactions among the two gets/puts. Each leaf migration should be in its own transaction to avoid too many write locks.