Object versioning in Ode
 Proceedings. Seventh International Conference on Data Engineering
INTRODUCTION Ode [2-4] is a database system and environment based on the object paradigm. It is an attempt to build a database system that offers one integrated data model for both database and general purpose manipulation. The database is defined, queried, and manipulated using the database programming language O++, which is an upward-compatible extension of the object-oriented programming language C++ [ Stroustrup 1986 ]. O++ extends C++ by providing facilities suitable for database
... ns, such as facilities for creating persistent and versioned objects, defining and manipulating sets, organizing persistent objects into clusters, iterating over clusters of persistent objects, and associating constraints and triggers with objects. Providing support for design environments, be it electrical computer-aided design (ECAD), mechanical computer-aided design (MCAD), or software computer-aided design (SCAD), has emerged as the major new application domain for database systems. It may also be said that these applications are the primary force driving the current interest in the object-oriented database systems. At present, there is little agreement on one uniform model for design databases, although some recent papers have articulated major needs [1, 5, 7-9, 13-17, 19-21, 24, 25, 28, 29, 32-34]. Consequently, O++ does not come with a "hardwired" design database model; instead, it provides facilities with which users can develop customized models that match their needs. In designing O++, we have distinguished between primitives and policies. Our design effort has been directed towards coming up with a few but powerful language primitives that allow a wide variety of policies to be implemented, and yet keep the language small. If some functionality could be realized using existing language facilities, we did not add new language primitives. For example, we consciously decided not to introduce new pointer types (such as own ref in  ) to model composite objects  with "local objects" which are deleted when the composite object is deleted because this can be simulated using C++ destructors. Similarly, we decided against a built-in change notification facility  because users can implement such a facility using O++ triggers. A critical requirement of CAD applications that is addressed by O++ is support for object versioning. Our design, although inspired by many of the earlier proposals [1, 5, 7-9, 13-17, 19-21, 24, 25, 28, 29, 32-34], differs significantly from them in that we focus on introducing a minimum number of concepts with precise semantics and integrating them seamlessly in a programming language. Object versioning in O++ is orthogonal to type, that is, versioning is an object property and not a type property. Versions of an object can be created without requiring any change in the corresponding object type definition, all objects can be versioned, and different objects of the same type can have a different number of versions. O++ supports both dynamic and static bindings to version references. Temporal as well as derived-from relationships between versions are also maintained automatically. Although we introduce few new language constructs, they are powerful enough to make O++ suitable as a platform for implementing a variety of versioning paradigms and application-specific systems. Indeed, we have successfully modeled a design database in • Temporal and derived-from relationships: Versions of an object should be ordered temporally according to their creation time, which is important for historical databases, such as those used in accounting, legal, and financial applications, that must access the past states of the database [14, 29] , and for supporting time in databases  . In addition, derived-from relationships reflecting the derivation history of the versions of an object should also be maintained to meet the requirements of the design environments in which several versions of a new design may be derived from the same design by making different changes to it [6, 21, 24] . The derived-from relationship can be used to store versions by storing their "differences" (called deltas [28, 32] ). Some current versioning proposals (GemStone  and POSTGRES , for example) constrain the version relationship of an object to be linear, which is inadequate for design databases. • Small changes should have small impact: Small operations should not cause major changes in the database. Thus, we do not provide version percolation [5, 13, 34] because creating a new version can lead to the automatic creation of a large number of versions of other objects. Users may implement version percolation as a policy by using other O++ facilities.