D. Jason Penney and Jacob Stein. Class modi cation in the GemStone object-oriented DBMS. In Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA), October 1987. 162  Home/Search   Document Not in Database   Summary   Related Articles   Check

....way an upgrade system can satisfy the conditions is by keeping old versions of all objects. This is because old versions preserve old interfaces and old object states. However versions are expensive, and to be practical, an upgrade system must avoid them most of the time. Some earlier systems [48, 7, 40] avoid versions by severely limiting the expressive power of upgrades (e.g. transform functions are not allowed to make method calls) others [5, 46] limit the number of versions using a stop the world approach that shuts down the system for upgrade and discards the versions when the upgrade is ....

....transforms. Some upgrade systems satisfy Condition M2 by using versions (so that when TF(x) runs it sees the old version of y) this is the approach taken in [5, 46] Others avoid the problem altogether by limiting the expressive power of transforms so that they cannot make method calls, as in [48, 7, 40]. A third possibility (and the direction we follow) is to satisfy M2 by controlling the order of transforms so that, when TF(x) uses y, x is transformed before y. Conditions M1 M3 together ensure upgrade modularity: transform functions encounter the expected interfaces and object invariants ....

[Article contains additional citation context not shown here]

D. J. Penney and J. Stein. Class modi cation in the GemStone object-oriented DBMS. In Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA), October 1987.

....Previous systems do not provide a satisfactory solution to these problems. Stop the world systems guarantee that applications and later upgrades cannot interfere with transform functions of an upgrade U , but they have diculty ordering transform functions within the same upgrade. Some systems [45, 6, 36] avoid problems by severely limiting the expressive power of transform functions, not allowing them to make any method calls. Others (e.g. 4] make the execution of transform functions order independent by maintaining two copies of the database during the upgrade. The transform functions ....

....deal with supporting application access to the same object via multiple potentially incompatible interfaces and are very di erent from the eciency and correctness issues in the evolutionbased upgrade systems. The schema evolution approach is used in Orion [6] OTGEN [36] O2 [24, 53] GemStone [12, 45], Objectivity DB [44] Versant [49] and PJama [5, 4] systems, and is the only approach available in any commercial RDBMS. None of the existing schema evolution systems provides both expressive and ecient upgrades. Furthermore, none bases the correctness of the upgrade system on the property of ....

D. J. Penney and J. Stein. Class modi cation in the GemStone object-oriented DBMS. In Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA), October 1987.

....requiring upgrades, which we expect to be the common case, since upgrades are likely to be rare (e.g. no more frequent than once a week or once a day) The results also show that the slowdown when upgrades are needed is small. There has been quite a bit of earlier work on upgrades in OODBs [4, 18, 15, 23, 22]. This work has either avoided lazy upgrades entirely, or under much broader conditions than are necessary; or the systems allow lazy upgrades even when they are unsafe. We discuss related work in more detail in Section 5. The paper is organized as follows. Section 2 describes our approach to de ....

....depends on the concrete system. Our discussion focusses on the schema evolution approach because it is most relevant to our work; a problem with the versioning approach is the huge amount of storage it requires. The scheme evolution approach is used in the commercial systems O2 [15, 3] GemStone [23, 8], Objectivity DB [22] and Versant [25] and in the research systems Orion [4] OTGen [18] and PJama [2, 14] and is the only approach available in commercial RDBMS. Very few of these systems support general transforms and lazy conversion: Gemstone and Orion do not support user de ned or complex ....

D.J. Penny and J. Stein. Class Modi cation in the GemStone Object-Oriented DBMS. In Proceedings 12 of the ACM Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA), 1987.

....for upgrading the persistent objects. These upgrades involve 2 changes to the code implementing the persistent objects, as well as changes to the persistent objects themselves. Much research has been done on software evolution in persistent object systems. PJama [3, 12] JPS [6, 31] and GemStone [17, 40] support some form of software evolution using modi ed JVMs. Software evolution cannot be implemented on unmodi ed JVMs. 2.4 Re ective Interface for Java Metaobject protocols [23] o er a principled way of extending the behavior of programs. Metaobjects can be used to transparently implement ....

D. J. Penney and J. Stein. Class modi cation in the GemStone object-oriented DBMS. In Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA), October 1987.

....available primitive schema changes with the axioms automatically ensures schema consistency, without need for explicit checking, as incorrect schema versions cannot actually be generated. For the change propagation problem, several solutions have been proposed and implemented in real systems [3, 11, 21]. In most cases, simple default mechanisms can be used or user supplied conversion functions must be de ned for non trivial extant object updates. A notable exception is [19] where a formal notion of logical consistency of the global approach is devised and proved decidable, in the context of a ....

D. J. Penney and J. Stein. Class Modication in the GemStone object-oriented DBMS. In Proc. of the Int'l Conf. on Object-Oriented Programming Systems, Languages, and Applications (OOPSLA), pages 111-117, December 1987.

....released to public domain shortly. 3 Running Example: The Delete Class Evolution Program Consistency management requires the speci cation of comprehensive constraints that must be checked to ensure that they are not violated. For example, the basic schema evolution primitive delete class(C i ) PS87] can only be applied when the class C i is a leaf class, i.e: sub(C i ) 1) However, while this is a necessary and sucient constraint for the delete of the HomeAddress class speci ed in the schema depicted in Figure 3, it is no longer a sucient stipulation for a schema that contains ....

D. J. Penney and J. Stein. Class modication in the GemStone object-oriented DBMS. In OOPSLA, pages 111-117, 1987.

....data translation language. This approach is a powerful one, but creation of the transformer is a manual process. More recent database systems generate transformation functions based upon the changes made to the type de nitions. Orion [Banerjee et al. 1987; Kim and Korth 1988] and GemStone [Penney and Stein 1987] are two object oriented database systems that provide some evolution support. In these systems, evolution is de ned in terms of primitive operations that change individual type de nitions, such as adding instance variables to a class, removing instance variables from a class, and renaming ....

Penney, D. J. and Stein, J. 1987. Class modication in the GemStone object-oriented DBMS. In Proceedings of the ACM Conference on Object-Oriented Programming Systems, Languages, and Applications (Orlando, Florida, October 1987), pp. 111-117.

....in more detail later) is de ned as the minimal superset of relevant schemata capable of holding all associated data without loss. Secondly, three principal data conversion mechanisms have been employed in the event of change. Firstly, data items are simply coerced to the new format as in [18]. Secondly, a lazy conversion mechanism can be used in which data are converted only when accessed [28] Thirdly, data are never physically converted and are always accessed through conversion interfaces [4] Finally, two query language extensions have been proposed which accommodate schema ....

Penney, D. and J. Stein: 1987, `Class modication in the GemStone objectoriented DBMS'. OOPSLA '87 (SIGPLAN Notices) 22(12), 111-117.

....available primitive schema changes with the axioms automatically ensures schema consistency, without need for explicit checking, as incorrect schema versions cannot actually be generated. For the change propagation problem, several solutions have been proposed and implemented in real systems [4, 12, 21]. In all cases, simple default mechanisms can be used or user supplied conversion functions must be de ned for non trivial extant object updates. As far as complex schema changes are concerned, 20] considered sequences of schema change primitives to make up high level useful changes, solving the ....

D. J. Penney and J. Stein. Class Modication in the GemStone object-oriented DBMS. In Proc. of the Int'l Conf. on Object-Oriented Programming Systems, Languages, and Applications (OOPSLA), pages 111-117, Orlando, FL, December 1987.

No context found.

D. Jason Penney and Jacob Stein. Class modi cation in the GemStone object-oriented DBMS. In Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA), October 1987. 162

No context found.

D. J. Penney and J. Stein. Class modi cation in the GemStone object-oriented DBMS. In Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA), October 1987.

No context found.

D. Jason Penney and Jacob Stein. Class modi cation in the GemStone object-oriented DBMS. In Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA), October 1987. 162

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC