The Management of Changing Types in an Object-Oriented Database

Annotation: This system (ENCORE) makes type changes by creating new versions. Objects (instances) retain their version unless they are coerced (transformed) to another version. To satisfy cross-version method calls/field accesses, each type has a version set interface (VSI). The VSI is the union of all methods anf fields of all the versions of that type; therefore, any program that accesses any version of the type can access the VSI correctly. Accesses are passed from the VSI to the underlying instance. If the access fails (e.g., because the target method/field doesn't exist or the access would read/write an illegal value), then an error handler in the VSI can substitute a response (e.g., default/alternate return value). This system handles not only changes to a type definition, but also changes to the type hierarchy. It also uses boolean formulas in type specs to automatically determine when handlers are needed. This system does not support changes to method/field semantics across versions (e.g., readOdometer() cannot change from returning miles to km; instead, you need to remove one method and add another). More importantly, the number of handlers scales as the square of the number of versions, because each time a version is added, handlers must be added for all the other versions.

BibTeX entry:

@inproceedings{skarra86management,
   author = {Andrea H. Skarra and Staney B. Zdonik},
   title = {The Management of Changing Types in an Object-Oriented Database},
   booktitle = {{OOPSLA}},
   pages = {483--495},
   year = {1986}
}