all existing objects, rename and retype, etc., are also possible. the evolution process can be automated via connection options. This is normally used in development mode and allows the schema to automatically evolve any mismatches on connect and continue preserving the existing objects. specific API’s can be used to dynamically evolve the database schema. This is an advanced topic, involving what's called Versant runtime classes. Basically, you can create completely dynamic schema structure for the database so that new classes and attributes can be created on the fly. If clients with the older schema continue to operate on the database, loose_schema_mapping in the application profile file should be set to true. Optionally, a utility can be started to crawl the database and force version migration of all existing instances. The general guidelines for schema evolution are that any schema changes can be made and existing instances preserved, without having to write custom evolution code, with the exception of two things: Changes to the middle of an inheritance hierarchy. Inserting a new class into the middle of a hierarchy is impossible without losing your existing objects, unless custom code is written to do this operation in a series of steps. Incompatible type changes like Array to a String. All other forms of evolution like renaming attributes, deleting leaf classes, adding leaf classes, adding new classes, adding or removing attributes, etc. can be done online and without custom code. If actions like setting non standard default values for newly added attributes are necessary, this can be done in callback functions within the objects. There are a set of standard object lifecycle callbacks that get invoked in activities like cache load. Those callbacks can be used to check for default values and take action if necessary. Persistent object lifecycle The lifecycle of an object load can be controlled on a use case basis. By default, objects are loaded only when they are sent a message. This includes the default behavior for queries which only return a collection of references to objects that satisfied the query predicate, not the actual objects. When an object is loaded, all its non-reference attributes (primitives) are also loaded and remaining reference types follow the same pattern as the referencing object. When a message is sent to an object VOD looks into internal structures to see if the object is already in client memory. If not, VOS does an