Stewart M. Clamen. Type evolution and instance adaptation. Technical Report CMU-CS-92-133, Carnegie Mellon University, June 1992.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....system. Each such system must identify objects needing to be transformed, run the transforms, and commit the changes. 7 Related Work There has been much research on software upgrades and data transformation covering a broad range of research topics. The work on schema or class versioning (e.g. [26, 49, 22]) considers multiple co existing versions of a schema or class. The work on object instance evolution (e.g. 8, 31] considers selective transformation of some but not all objects in a class. The work on hot swapping of modules (e.g. 36, 32, 37] is concerned with updating a class while there ....

S. M. Clamen. Type evolution and instance adaptation. Technical Report CMU-CS-92-133, Carnegie Mellon University, June 1992.

....and class versioning. In the evolution approach the database has one logical schema to which modi cations of class de nitions are applied. Object instances are converted (eagerly or lazily, but once and forever) to conform to the latest schema. In the schema or class versioning approach (e.g. [19, 47, 14]) multiple versions of a schema or class can co exist. Instances can be represented as if they belong to a speci c version of their class, but how this is done (e.g. by creating a separate instance or by keeping one version speci c copy and dynamically converting it as needed) depends on the ....

S. M. Clamen. Type evolution and instance adaptation. Technical Report CMU-CS-92-133, Carnegie Mellon University, June 1992.

....and class versioning. In the evolution approach the database has one logical schema to which modifications of class definitions are applied. Object instances are converted (eagerly or lazily, but once and forever) to conform to the latest schema. In the schema or class versioning approach (e.g. [19, 47, 14]) multiple versions of a schema or class can co exist. Instances can be represented as if they belong to a specific version of their class, but how this is done (e.g. by creating a separate instance or by keeping one version specific copy and dynamically converting it as needed) depends on the ....

S. M. Clamen. Type evolution and instance adaptation. Technical Report CMU-CS-92-133, Carnegie Mellon University, June 1992.

....Frame3 is a class W1 wheel compref W3; frame compref Frame3; wheel compref W1; class MountainW class W22 9 3.2 EVOLUTION OF CLASSES Database Schema Evolution Changes to the schema of a database can hardly ever be avoided. This makes schema evolution a relevant topic of database research [Skar86, Bane87, Penn87, Skar88, Clam92]. A principal assumption in database schema evolution is that instances can be converted. This assumption is based on the principle that schema constantly describes the same (or at least almost the same) real word entities. Schema modifications just slightly alter the way those entities are ....

Stewart M. Clamen. Type evolution and instance adaptation. Technical Report CMU-CS-92-133, Carnegie Mellon University, School of Computer Science, CMU, Pittsburgh, PA 15213-3891, June 1992.

....how objects may be converted to comply with the most recent specification of its class. All application programs must be modified and recompiled in accordance with the most recent specifications. In contrast, the schema versioning approach (e.g. Avance [3] Encore [4] CLOSQL [5] Clamen s work [6] and Bratsberg s work [7] does not obsolete former specifications. Existing applications are unaffected by change, and may regard the database in the same way as before the modification was performed. In this way the schema versioning approach promotes change transparency, there is no need for ....

....be perceived to be a a member of different classes. Existing SMM work disregards this aspects of schema modifications, which is particularly important to consider in the case of class hierarchical changes. Finally, a problem with existing SMM work is that dependencies between schema spec 1 For [6, 7] coercion functions are more like triggers invoked upon object mutation to ensure the effect is consistently propagated to other class version perspectives of the object. 4] adopts a different scheme, for which coercion functions are defined between each class version and the totality of ....

[Article contains additional citation context not shown here]

Stewart M. Clamen. Type Evolution and Instance Adaptation. Technical Report CMU-CS-92-133, School of Computer Science, Carnegie Mellon University, Pittsburgh, PA 15213-3890, USA, June 1992. 27 pages.

....to dynamically changing a database schema. Schema evolution ( BKKK87, MSOP86, LH90, BBB 88, Bar91, TS92] systems tend to focus on how changes to the schema are described and ways of ensuring that changes do not invalidate the database contents. Versioning approaches ( BB88, SZ86, Zdo90, MS93, Cla92, Bra93] focus on how to allow multiple versions of an object to co exist at run time. The most obvious similarity between such database systems and DRASTIC is that a process booted over a DRASTIC platform with a persistent store must be able to access the state in the store after any evolution. ....

S. M. Clamen. Type Evolution and Instance Adaptation. Technical Report CMU-CS-92-133, School of Computer Science, Carnegie Mellon University, Pittsburgh, PA 15213-3890, USA, June 1992. 27 pages.

....task of the system to ensure inter version consistency, and is performed within the SP itself. Dependency relationships are specified in the Version Linkage Language (VLL) which describes at a declarative level how representation of the new class version relates to the SP. Adopting ideas from [Cla92, Bra93], there may be different dependency relationships between (groups of) attributes: Representation may be derivable from other representation (to indicate that one value may be computed from others) it may be dependent (to indicate that there is a dependency, but the value cannot be computed) it ....

Stewart M. Clamen. Type Evolution and Instance Adaptation. Technical Report CMU-CS-92-133, School of Computer Science, Carnegie Mellon University, Pittsburgh, PA 15213-3890, USA, June 1992. 27 pages.

....This avoids conversion of the clients to conform to new class versions. Conversion might be an error prone and costly process. Class versioning also prevents information to be lost. ABB 83] supports class versioning by substitute read and write functions, SZ87] by error handlers, Zdo90, Cla92] by multiple views to objects. Database views [GPZ88, KDN90, Ber92] is a general technique for having derived information, and it may successfully be used for class evolution. However, often it is not possible to create objects of views and it is not possible to add representation in views with ....

....treat null values that did not appear prior to the evolution. 5.2 Examples of Class Evolution We will give some examples of class evolution. The syntax of intent definitions is similar to the syntax of class definitions in C . The first example is a class versioning example based on one from [Cla92] The intent of Student1 is defined below. intent Student1 public: string name; string addr; degreeprogram pgm; classdomain cl; set of(link(Course) course; Below, the initial definition of the extent of Student1 is given. The L subscript on a class name designate the local extent. ....

S. M. Clamen. Type Evolution and Instance Adaptation. Technical Report CMU-CS-92-133, School of Computer Science, Carnegie Mellon University, Pittsburgh, PA 15213-3890, USA, 1992.

....and to share the extent. This avoids conversion of existing applications to conform to new class versions. Conversion might be an error prone and costly process. Class versioning also prevents information from being lost. 1] supports class versioning by substitute read and write functions, and [13, 7] by multiple views. 11] is a proposal for versioning of entire schemas in object oriented databases. Class integration is usually done additively by views, e.g. 9] These constructs have many similarities, yet still, they are different. Common to the additive approaches is that the extents (the ....

S. M. Clamen. Type Evolution and Instance Adaptation. Technical Report CMU-CS92 -133, 29 p., School of Computer Science, Carnegie Mellon University, Pittsburgh, PA 15213-3890, USA, June 1992.

No context found.

Stewart M. Clamen. Type evolution and instance adaptation. Technical Report CMU-CS-92-133, Carnegie Mellon University, June 1992.

No context found.

S. M. Clamen. Type evolution and instance adaptation. Technical Report CMU-CS-92-133, Carnegie Mellon University, June 1992.

No context found.

Stewart M. Clamen. Type Evolution and Instance Adaptation. Technical Report CMU-CS-92133, School of Computer Science, Carnegie Mellon University, Pittsburgh, PA 15213-3890, USA, June 1992. 27 pages.

No context found.

S. M. Clamen. Type evolution and instance adaptation. Technical Report CMU-CS-92-133, Carnegie Mellon University, June 1992.

No context found.

Stewart M. Clamen. Type evolution and instance adaptation. Technical Report CMU-CS-92-133, Carnegie Mellon University, June 1992.

No context found.

Stewart M. Clamen. Type evolution and instance adaptation. Technical Report CMU-CS-92-133, Carnegie Mellon University, June 1992.

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