Recoverable Storable Facility

17/30/02 dbh0201

The Recoverable Storable Facility

A Mismatch Correction Mechanism for Handling Schema Evolution in an Eiffel System

by

Darren B. Hiebert

Recoverable Storable Facility

27/30/02 dbh0201

References

Section 31.3 of Object-Oriented Software Construction, 2nd Edition, by Bertrand Meyer (OOSC), contains a discussion of the problem of schema evolution in an object-oriented system, and loosely defines a proposed solution.

Recoverable Storable Facility

37/30/02 dbh0201

Problem

How do you recover an object from persistent storage when the generating class of the stored object has changed since it was stored (e.g. via STORABLE)?

If the object was stored using the facilities of the ISE (now Eiffel Software) class STORABLE, the system will exit with a retrieval exception. This discourages its use in any application where

preservation of data is important. Recoverable Storable is an implementation of the

solution proposed in OOSC, with minor variations.

Recoverable Storable Facility

47/30/02 dbh0201

Definitions

“Schema evolution occurs if at least one class used by a system that attempts to retrieve some objects (the retrieving system) differs from its counterpart in the system that stored these objects (the storing system).” [OOSC, p. 1041]

“Object retrieval mismatch, or just object mismatch for short, occurs when the retrieving system actually retrieves a particular object whose own generating class was different in the storing system.” [OOSC, p. 1041]

Recoverable Storable Facility

57/30/02 dbh0201

Solutions

Throw away pre-existing stored objects Simplest approach Upsets users

One-time, en-masse, conversion of stored objects (i.e. “database conversion”) Requires down-time of application Multiple conversions require careful sequencing

On-the-fly object conversion A more general solution than en-masse conversion,

allowing it to be used to implement en-masse conversion

Requires no down-time of application

Recoverable Storable Facility

67/30/02 dbh0201

On-the-fly Object Conversion

Consists of three phases: Detection

Retrieval subsystem detects object mismatches. Notification

Retrieval subsystem notifies retrieving system of object mismatch (appropriate correction is application-dependent).

Correction Retrieving system corrects object mismatch using

domain-specific knowledge.

Recoverable Storable Facility

77/30/02 dbh0201

Detection of Object Mismatch

Two Approaches: Nominal

Reads version number of generating class recorded in object.

Requires low-level run-time support. Structural

Detected by recording, for each object, “a class descriptor deduced from the actual structure of a class.” [OOSC p. 1043]

The class descriptor includes “the class name, the list of its attributes, each characterized by its name and its type” (strategy C3, per OOSC). [OOSC, p. 1043]

Recoverable Storable Facility

87/30/02 dbh0201

Notification of the Retrieving System

Proposed solution from OOSC: Class ANY contains a procedure correct_mismatch,

which is called on the retrieved object by the retrieval subsystem, and which is responsible for handling the mismatch.

Class ANY also contains a “once” function, mismatch_information, of type ANY to provide correct_mismatch with more information.

Recoverable Storable Facility

97/30/02 dbh0201

Correction of Object Mismatch

Proposed solution from OOSC: The procedure correct_mismatch from ANY has a default

implementation of raising an exception. A class which can undertake object mismatch correction redefines

correct_mismatch. Two mismatch scenarios must be considered:

Removal of attributeNo action required, since attribute is no longer referenced

Addition of new attributeRequires initialization of some kind

Other problems (e.g. change of attribute name or type) are reducible to a combination of the above two problems.

Recoverable Storable Facility

107/30/02 dbh0201

Addition of Attribute

The retrieval subsystem initializes new attributes to default values (as in object creation).

The modified generating class of the retrieved object may impose constraints upon the value of the new attribute (expressed as class invariants) and has sufficient knowledge to initialize it. The purpose of a creation routine is to establish the

class invariant of the newly created object. Likewise, the purpose of correct_mismatch is to re-

establish the class invariant of the retrieved object. The correct_mismatch procedure may also require

access to removed or original attributes in order to do its job.

Recoverable Storable Facility

117/30/02 dbh0201

Recoverable Storable

Decomposes objects in the supplied object tree into a meta-representation

Constructs a class descriptor by using the reflection facilities available in ISE Eiffel through its INTERNAL class

Uses STORABLE to store the meta-representation of the object tree

Provides capability to rename a class Handles the case where the name of the generating

class of a retrieved object has changed New extension to basic solution proposed in OOSC Name translation can be controlled programmatically

or via a text file referenced by an environment variable

Recoverable Storable Facility

127/30/02 dbh0201

Recoverable Storable (continued)

Since correct_mismatch is not included in the delivered ANY class, the proposed solution from OOSC would require a modification to ANY. To avoid modification of the delivered ANY class,

Recoverable Storable introduces, instead, the class CORRECTABLE, containing correct_mismatch and mismatch_information.

If an object mismatch is detected and its generating class in the retrieving system is a descendent of CORRECTABLE, then correct_mismatch is called.

CORRECTABLE and correct_mismatch are deferred, since a default implementation is unnecessary.

Recoverable Storable Facility

137/30/02 dbh0201

Recoverable Storable (continued)

The once function, mismatch_information, is of type HASH_TABLE [ANY, STRING] instead of ANY, returning a table of original attribute values hashed by attribute name. All of the original attributes of the retrieved object are

available to correct_mismatch.

Recoverable Storable Facility

147/30/02 dbh0201

Class Diagram

Recoverable Storable Facility

157/30/02 dbh0201

Limitations of Implementation

Available only on ISE Eiffel Dependent upon implementation of STRING and ARRAY not

changing (STRING actually changed once, requiring mitigation) Cannot detect the change of an attribute type when one reference

type is changed to another Cannot restore changes to attributes of type INTEGER_8,

INTEGER_16, INTEGER_64, WIDE_CHARACTER, or BIT Enhancements to INTERNAL in EiffelStudio 5.2 will allow for

support of the new integer types. Lack of capability of INTERNAL to store an attribute of expanded

type requires use of an external call to a low-level run-time routine, thus preventing a pure Eiffel solution.

Recoverable Storable Facility

167/30/02 dbh0201

Potential Improvements

Use XML to store meta-representation instead of using STORABLE. Removes dependency upon an unchanging

implementation of STRING and ARRAY types. If the necessary features are added to INTERNAL, the

remaining implementation limitations will be removed.

Recoverable Storable Facility

177/30/02 dbh0201

Getting Recoverable Storable

The latest version of the Recoverable Storable Facility can be found at:

http://DarrenHiebert.com